Boost logo

Boost :

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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at