Re: [boost] [outcome] outcome without empty state?

Subject: Re: [boost] [outcome] outcome without empty state?
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2017-05-25 10:12:59

Le 25/05/2017 à 01:45, Gavin Lambert via Boost a écrit :
> On 25/05/2017 07:54, Niall Douglas wrote:
>>> 3. A default-constructed result<T> is initialized as if
>>> `result<T>{error_code_extended{}}`.
>>
>> I feel lots of gut feelings against that default. It seems a bit of a 
>> hack.
>>
>> Also, I remember Expected used to do this as a default, but it was
>> undone. I would assume someone from WG21 gave a very good reason why.
>>
>> I will say that I cannot think of a good technical reason not to default
>> construct to a null error_code. But just because you can doesn't mean
>> you should.
>
> Visions of "An error occurred: The operation succeeded" dialog boxes 
> scroll through my brain.
Yes, I don't want that.
>
> I like Peter Dimov's suggestion of defaulting to a non-null error 
> code, especially where T is not void.  This requires explicitly 
> acknowledging success.  (I'm not sure about the case where T is void.  
> I'm initially inclined to want the same for consistency, but I suspect 
> that would be too painful to actually use in practice.)
>
If it is uninitialized on the default constructor it will force you as 
well to state explicitly success or failure. No default is good.
If you want to state explicitly an error until something else is said 
later on initialize it explicitly to this error.

More I think on the uninitialized default constructor, more I like it. 
No surprise.
"Explicit is better than Implicit"

Vicente