Re: [boost] [gsoc-2013] Boost.Expected

Subject: Re: [boost] [gsoc-2013] Boost.Expected
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-04-21 03:17:05

Le 20/04/13 20:45, Pierre T. a écrit :
> On 04/20/2013 03:14 PM, Vicente J. Botet Escriba wrote:
>> Le 20/04/13 14:44, Pierre T. a écrit :
>>> On 04/20/2013 11:36 AM, Vicente J. Botet Escriba wrote:
>>>> Do you think that expected and/or expected_or_error could/should 
>>>> have value semantics, that is define operator==?
>>> I don't have any use cases where expected/expected_or_error would 
>>> have value semantics.
>>> Even if the underlying value has value semantics, you can't compare 
>>> exceptions and you rarely compare two error code encapsulated into 
>>> two variables (of course you often compare a variable and a constant 
>>> error code).
>>> So, unless we give me good arguments, I would consider it as entity 
>>> semantics.
>> I was wondering as optional<T> has value semantics and no value is 
>> different from any optional valued. I don't know yet if it has a sens 
>> to define it for expected_or_error and you are right we need a valid 
>> use case.
> Do you say there is a sens to define it for expected ? How do we 
> compare two exceptions ? 
I don't know. We could consider that the exception is not part of the 
expected class in the same way as we don't take in account an internal 
mutex when we compare 2 synchronized_value.
Comparing two valued expected would rely on the type T, comparing to 
exceptional expected succeeds always (as if the value was not set) and 
mixing them fails. The main difference is that here the exception could 
be visible while in synchronized_value the mutex is hidden.

Let comparison out of the scope of the proposal for the time been.

Best,
Vicente