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
>>> 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.
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk