Re: [boost] [outcome] How to drop the formal empty state

Subject: Re: [boost] [outcome] How to drop the formal empty state
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2017-05-25 15:46:46

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