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.