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