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-26 16:32:20

Le 26/05/2017 à 18:07, Niall Douglas via Boost a écrit :
>>> I have been persuaded by argument here that default construction to
>>> empty is in fact a defect in the design. The formal empty state ought
>>> to *always* be explicitly constructed, and **never** occur implicitly.
>>> I have logged this defect to
>>> https://github.com/ned14/boost.outcome/issues/44.
>> I don't think I agree with that. The whole point of having a singular
>> empty state is to default-construct to it so that the mistake of failing
>> to assign to the default-constructed result/outcome can be detected. This:
>>
>> result<T> function()
>> {
>>     result<T> r;
>>
>>     // do things that put something into r
>>
>>     return r;
>> }
>>
>> where the "do things" part sometimes fails to put something into r.
> But you still get exactly that *if* you ask for it:
>
> result<T> function()
> {
>     result<T> r(empty);
>
>     // do things that put something into r
>
>     return r;
> }
>
> Combined with the never-empty guarantees, this new behaviour makes the
> empty state completely impossible unless someone asked for it at least
> once somewhere. I like that.

I'm missing surely something. Do you consider that you support the 
never-empty warranties when you have already the empty alternative?
>
>> If you don't default-construct to empty, you pretty much lose the point
>> of having empty.
> I am currently minded that default constructing an outcome or result is
> not possible if T does not have a default constructor. If it does, it
> default constructs to a default constructed type T.
>
> This matches the current behaviour of Expected, though Vicente is
> currently planning on eliminating the default constructor entirely. If
> he gets LEWG buy in to that design, I am minded to match Expected on
> this in outcome/result: no default constructor, not ever.
I believed that you needed the empty state at the interface level. Are 
you saying that Outcome will not have this empty state?
It seems there are some that find it useful to have such optimization 
for optional<expected<T, E1, E2>>.
>
> The reason my opinion has been changed on this is that I cannot think of
> any situation where you really need a default constructor or else
> everything blows up and the end user reaches a showstopping game ever
> situation. If someone can suggest one, I think we'd all change our opinion.
>
I believed that outcome was a model for optional<expected<T, E1, E2>>.

Are you saying that outcome will now be a model of expected<T, E1, E2> 
if expected was variadic on the Errros parameters as I have suggested in 
another thread?

Vicente