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

Subject: Re: [boost] [outcome] outcome without empty state?
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-05-26 23:43:33

>>> When it comes to converting from `prepare_expected<T, E>` to `expected<T,
>>> E>`, you have plenty of choices: require manual conversion,
>> narrow-contract
>>> to be checked, a defensive if and throw... I am just not sure if
>>> performance can be negatively impacted with this.
>>
>> I originally considered this design for Outcome's API.
>>
>> I ended up rejecting it because it's superfluous if you have correctly
>> designed your expected/outcome/whatever in the first place.
>>
> 
> What does "correctly" mean here?

Well, indeed :)

Where I'm aiming, as you'll see in the summary design document I'll post
shortly, is that the implicit conversion semantics will provide the
ability to use a less representative variety to construct things, but
return into a more representative variety.

Niall

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