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-26 17:26:08

>>> 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 that's exactly the crux of the debate isn't it?

How much should the specific type of object you choose to return T|E
exactly match the contract of that function?

It's easy to say "exactly match". But in a large code base, too many
slight variants of an Outcome significantly increases cognitive load on
programmers having to remember what each one of dozens of Outcome
variants mean and how they are slightly different.

Nevertheless, I can see a good argument for result<T> vs result_e<T> as
you suggest. It does increase the clarity of the API's public contract.
But one can also go too far.

I think, in combination with my proposed typedef factory, we can reach a
happy medium somewhere. Obviously there would be implicit conversion
from outcomes incapable of empty state into outcomes capable of it, but
not the other way round.

So like at the moment you can return a result<T> into something
accepting an outcome<T> implicitly, you could implicitly return a
result<T> into something accepting a result_e<T>, where result_e<T> is
empty | T | error_code_extended.

What do you think?

Niall

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