Le 19/05/2017 à 09:01, Andrzej Krzemienski via Boost a écrit :
2017-05-19 0:49 GMT+02:00 Niall Douglas via Boost <boost@lists.boost.org>:
No undefined behaviour needed, and you can write your code using
Outcome with the hard assumption that o.error() will always return an accurate view of the current state. No need to check .has_error(), or anything like it.
Modulo this situation with `http_error::ok == 200`. But with this you are also saying, the library provides two ways for checking if you have an error:
o.has_error(); // option 1 o.error() == std::error_code{}; // option 2 In the current standard expected proposal, we have an open point about a has_error(exp, err) that return true if exp has no value and the errror is the provided as parameter. This has the advantage to not throwing. And by describing clear semantics for option 2, you are saying, it is equally fine to use option 2 for checking if we have an error. This encourages the usage of option 2, but I would not want my colleague programmers to start using this syntax, because I then cannot tell proper usages from inadvertent omissions. And reading the value of `error()` without having confirmed that some error occurred is almost surely a bug, even if you can assign a well defined semantics in `boost::outcome` for it.
Remember, expected<std::error_code, std::error_code> is legal, though Outcome's Expected doesn't allow it. Why?
Best, Vicente