Le 25/05/2017 à 16:30, Niall Douglas via Boost a écrit :
1b. make them default-construct to `make_error_code( outcome::errc::uninitialized_result )`. I am not keen on magic constants in an errored state. I am also not keen on overloading the errored state with alternative meaning. The errored state is for indicating an end user operation failed somehow, not for detecting logic errors in user code.
This is precisely why I added a formal empty state, and default initialised to that. Because it causes behaviour different to valued or errored, it **very** effectively traps logic errors during code development. On **many** occasions it has successfully illuminated poorly thought through code that I have written by bringing to my attention - early and very obviously - that someone was very wrong. I am absolutely convinced it is a great design choice.
And I don't like to wave this flag too hard, but I have been using these objects in anger in my own code for two years now. I have a wealth of experience in using these objects.
Now, all that said, my strongest argument in favour of a formal empty state is one based on debugging. In release builds of finished code I don't find the logic error argument compelling. My strongest argument now is how it saves writing boilerplate for sending out-of-band signals, for terminating loops and such, and those are not strong arguments seeing as the end user could just send a bool& and achieve the same. So for non-debug builds, I can live with no empty state which traps logic problems.
I'd therefore be happier with default construction giving uninitialised contents, or a default constructed T or E. No overloading state of E.
We agree here :) Vicente