Boost logo

Boost :

Subject: Re: [boost] [outcome] Ternary logic -- need an example
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-05-18 14:41:26

>> I don't know if it would be worthwhile to try to optimise storage for
>> that case. [result<optional<T>>]
> An interesting point, because this is an argument in favor of returning
> by value from result<>::value() - I can synthesize an optional<T> on
> demand instead of storing one. (Return by reference mandates having an
> optional<> object stored.)

I did consider returning optionals which might be empty instead of
throwing an exception. Syntactically, the user must then do the check
for state after the .value() if they want to avoid a throw, plus you now
get ugly outcome.value().value() everywhere. I felt that undesirable.

> Also applies to other possible combinations such as expected<expected<T,
> E1>, E2>, outcome<expected<T, E>>, and so on that can all in principle
> be flattened into a single variant under the hood.

Earlier Expected proposals had all sorts of useful semantics for nested
expected. They have been removed from the most recent proposal.


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at