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

Subject: Re: [boost] [gsoc-2013] Boost.Expected
From: Pierre T. (ptalbot_at_[hidden])
Date: 2013-04-21 14:56:52

On 04/21/2013 09:17 AM, Vicente J. Botet Escriba wrote:
> 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
>
I think this behavior could lead to potential mis-understanding (and 
possibly bugs ?) from the user. However, you are right, we'll discuss it 
later if needed.

Best regards,
Pierre T.