Re: [boost] [outcome] Possible extensions/changes to std::experimental::expected

Subject: Re: [boost] [outcome] Possible extensions/changes to std::experimental::expected
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2017-05-25 15:43:07

Le 25/05/2017 à 16:55, Niall Douglas via Boost a écrit :
>> 4. About comparisons
>>
>> Outcome doesn't implement comparisons between Outcomes. He pretend that
>> we don't need them.
> I don't pretend we don't need them. I say that people who store Expected
> in an associative map need their head examined. And if they really,
> really want to, they can supply a custom comparison function to the map.
> We don't need default ordering operators if it means losing implicit
> conversion and creating yet more needless boilerplate for end users.
You and Andrzej have almost convinced me ;-)

>
>> 5. About the exception to throw
>>
>> std::experimental::expected throw bad_expected_access<E>. I adopted the
>> design of optional and bad_optional_access
>>
>> We could have as well a bad_expected_access_base class as Outcome has.
>>
>> My question is why don't throw directly E?
> Throwing types without a vtable is punished badly in optimisation by
> some compilers e.g. GCC. Before you ask, no I don't know why.
This is a compiler problem, isn't it?
I don't know how I could take this argument for the standard.
>
> Throwing types not derived from std::exception I think that ship sailed
> from C++ a long time ago. I think WG21 would vote against it.
>
Maybe you are right. We have 1/2 of possibilities ;)

If a had a expected<T, E1, ..., En> it seems natural to me that the 
exception to thow are the Ek directly.
If the user consider that this Ek must inherit from std::exception, then 
he can do it.

The library will be not throwing an exception not derived from 
std::exception. This is on the user land.

E.g. The current standard library could throw/re-throw a user exception 
that doesn't derives from std::exception.

Vicente