On 30/05/2017 00:25, Vicente J. Botet Escriba wrote:
Le 29/05/2017 à 17:05, Niall Douglas via Boost a écrit :
I can not ignore this Outcome review, but I have not see too much people saying that the semantic you have done to this functions is the good one. Strange. I've been surprised at how little criticism there has been of my design choices. Silence can be interpreted both ways I guess.
he he, you find that your library has not been criticized?
People started off with a lot of problems with my design choices for Outcomes. But as discussion proceeded and people thought through the balance of factors, approximately half ended up deciding that my original design was well balanced, including the formal empty state. Of the remaining other half, many wanted narrow observers with __builtin_unreachable() being used to enforce static correctness checking at compile time. I can see value to that, so I'll be adding varieties implementing those with implicit conversion on demand to the runtime checked varieties. The only other design criticism I've noticed is that APIs returning Outcomes are not indicating via the type returned whether the empty state is a valid return or not. I think that important, so I will provide varieties to represent that situation too. The common underlying storage has not been criticised apart from by yourself Vicente, nor the design of "API personalities" sitting on top of the common storage (again, apart from yourself). People aren't happy with the profusion of varieties thinking that a single object design should rule them all as is the Boost way, but I haven't got the sense it's a showstopper for a future acceptance. My argument that it's the same object, just wearing a different face depending on what variety the programmer has selected, appears to have been accepted as viable, if non-ideal in each individual's opinion.
I do agree with this philosophy, but if you're going to go narrow, you need to go narrow on everything including .value(). You need to consistently choose one or the other. No middle ground.
value() id wide operator*() is narrow.
Why? Just because optional made that mistake? If narrow is good, make the entire thing consistently narrow. I have no objection to all member functions all being narrow. The programmer, knowing that it is a narrow-only type, can not accidentally write the wrong thing. It helps code auditing to be consistent and simple. If you want to mix narrow and wide observers into the same object, I cannot abide by making less programmer typing choose the narrow UB observers. It is bad design, and I think it will cause programmers to inadvertently write UB code out of laziness. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/