I would agree. But well, we were outvoted. And that probably means rejection of this library, as the presented library does not implement what the majority want (yet).
How do you count the votes? How many votes did you count? What option did I vote for?
It's more a case of me judging where majority opinion is at, and deciding on if I can accommodate that majority opinion at the same time as preserving what I think are red line issues and design concerns. I appreciate that this philosophy of giving people what they want instead of the "correct" single vision is not popular here, but I believe in market evolution and competitive pressure. So the right design or designs would win out in time through a process of evolutionary pressure, and it's my job to select the designs to compete and how they should interoperate with one another, and then throw it onto the market to decide what is the best mix. I personally think I'll have very little use for the narrow contract varieties, but I've been convinced by the non-empty-capable vs empty-capable distinction because it means that my public API functions can specify via the type they return whether an empty return is possible or not, thus more accurately specifying their public contract. That, and the fact I can still use a receiving empty-capable variety for detecting when loops haven't found what they were looking for etc I find very compelling.
I indicated my preference towards not having initiali empty state (default constructor), on basis that I cannot think of a use case for it. Since you are still trying to provide `optional_result`, it means you must see some use case for it.
I see a lot of use for it. I also have a lot of code written which makes great use of that empty state. The fact that the empty state can never arise on its own and can only result from the programmer introducing it into a logic chain somewhere I think is something that people either get and say "that's very useful" or they don't get and say "empty states need to be removed entirely as an obvious design mistake". I am battling, sometimes, that people think the empty state has something to do with variant's valueless_by_exception(), that it arises due to an exception throw. That isn't the case in Outcome: empty is a truly third state. The fact I've chosen that non-empty-capable silently converts to empty-capable I also think is underappreciated. It enables the best of both worlds by closely aligning the type used to the exact use case. Some would say that is a lack of vision and willingness to decide on my part. I would claim it to have been my original vision for this library all along.
Having so many types doesn't look good to me either. I would be more comfirtable with result<> having empty state but with additional observers with narrow contract.
People are getting hung up on the multitude of types. They're just API personalities onto an identical implementation. They're just different ways of speaking to the same variant storage, so basically we are using the C++ type system like a pair of glasses onto the exact same view, with well defined rules for changing which glasses you're wearing as demand presents. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/