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:36:21

Le 26/05/2017 à 18:16, Niall Douglas via Boost a écrit :
> On 26/05/2017 15:23, Peter Dimov via Boost wrote:
>> Niall Douglas wrote:
>>
>>> But after I built up some experience, now I tend to write this instead:
>>>
>>> result<Foo> something()
>>> {
>>>    result<Foo> ret(Foo());
>>>    Foo &foo = ret.value();
>>>    ... build foo ...
>>>    return ret;
>>> }
>> This takes us back to "what if due to a logic error the code that should
>> build `foo` doesn't?"
>>
>> And since you've constructed `ret` to non-empty, the point of empty is,
>> again, lost.
> But if I am writing my implementation that way, it is because there is
> no purpose here to my function returning empty. Else I would implement
> it differently.
If the function can not return empty it should use another type, isn't it?
Well I can admit that you must follow a specific protocol and return a 
result<T> even if in this specific case it cannot be empty.
>
> I appreciate that the above is me speaking vaguely from experience and
> without concrete evidence. But I think most programmers, once they are
> using these objects for a while, will start to naturally write code
> which never *could* return an empty object if returning an empty object
> makes no sense for that function. Equally, if some function could return
> an empty object, the programmer will structure their code appropriately.
If we don't have cases where we can return empty, I don't see why we 
want to support it.
Vicenet