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.