Re: [boost] [outcome] Possible extensions/changes to std::experimental::expected

On 25/05/2017 19:44, Vicente J. Botet Escriba wrote:

3. uninitialized default constructed expected

I've already stated my opinion on this elsewhere.

Outcome doesn't implement comparisons between Outcomes. He pretend that we don't need them. In addition the mix of comparisons and implicit conversion give us some surprising cases as described in Andrzej blog.

I agree with Niall -- putting one directly in an ordered collection is bizarre and if someone really wants to do that then it should be left up to them to define what ordering makes sense to them. operator< should absolutely not be implemented and I would hesitate before providing any free standard ordering methods.

The implicit conversion from T to expected is a consequence of wanting that expected should behave like a T. But this is not right. A expected is not a T.

Implicit construction does not imply is-a, it implies is-superset-of. Which is true, expected is a superset of T. As the intent is to naturally convey T as a wrapped return value of a method, the implicit construction allows "return some_t_value;" as a simplified syntax and the most natural one. Forcing users to use "return make_expected(some_t_value);" instead would be a disservice and discouragement, I think. (In order to imply is-a then there must be a reverse conversion operator from expected to T, and that definitely should not exist, not even as explicit.) The caveat (and the reason make_unexpected is required) is where T and E are compatible, eg. expected or expected etc. In this case there is a possibility that someone intending to return an error value might forget to use make_unexpected and end up with code that compiles but is not correct. Requiring explicit make_expected does mitigate this case but I'm not sure it's worth the hassle. Outcome uses a different mitigation by restricting the possible types of E, rendering the above case very unlikely (although not impossible, since outcome is legal).

My question is why don't throw directly E?

Some are requesting a way to get a specific exception from E, but either there is one exception that works for all and we can set it using some kind of trait or we need to add a trait parameter to expected to the the mapping :(

Do we really want this to be configurable?

At least where E happens to be std::error_code it would be nice if it threw std::system_error, since that is the exception designed for such things. Otherwise I have no opinion.