Re: [boost] Boost.Outcome review - First questions

Subject: Re: [boost] Boost.Outcome review - First questions
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2017-05-25 09:58:53

Le 24/05/2017 à 22:41, Niall Douglas via Boost a écrit :
>>> Compilers spotted the common outcome::value_storage during moves when it
>>> was identical, and totally eliminated any memory copies.
>> Okay, so the single thing outcome::outcome provides is the conversion
>> from the other Outcomes.
>> I believe this is great and I will add it to the open question for
>> std::expected
>
>
>>> clang 4.0+ and GCC 6.0+ with -O3 optimisation appear to now be clever
>>> enough to spot trivial move constructors and trivial types, and not copy
>>> memory when the bits in memory would not change.
>> Do you mean that now we can use optional and expected without any
>> performance penalty and that the design of Outcome is not needed any more?
> This is correct. But to be specific, the **storage layout** design of
> Outcome is not needed any more with very recent compilers. I don't think
> the current approach is damaging though.
Up to you. KISS as much as possible.
>
>>> Currently every time I commit to the git repo there is a new version of
>>> Outcome. The ABI is permuted with the SHA of the git. This prevents
>>> unstable versions of Outcome conflicting with different unstable
>>> versions of Outcome in the same process.
>> Hugh. I don't see how would someone like to use two unstable version of
>> the same library.
> In large orgs, one team may use one version of a library and another
> team another version. Each team does not realise that the other team
> does this. When someone else combines the libraries into a single
> executable, boom!
I work on large org and each time we take a 3pp library we master it at 
the project level.
There is no chance we can use different versions of the same library and 
even less to use unstable versions.
Others could need what you offer, but I believe it is too much.
>
>>>> No this example doesn't show any advantage of Boost.Outcome, quite the
>>>> opposite. However the other example that Andrzej has posted recently is
>>>> a better example as I have already said as a response.
>>> The only difference was returning result instead of outcome, and
>>> removing the exception throwing function call. Otherwise the examples
>>> are identical.
>>>
>> The return value is very important; the example show an important thing
>> of Boost.Outcome: error propagation.
> But we were propagating exception_ptr before. That is also error
> propagation. I don't get the difference.
>
I believe the tutorial should show how errors are propagated using 
outcome classes in a transparent way, not showing how we can propagating 
exceptions by hand.

Vicente