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

Subject: Re: [boost] [outcome] How to drop the formal empty state
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-05-25 14:30:15

> 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.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/