Re: [boost] [outcome] How to drop the formal empty state

2017-05-25 17:14 GMT+02:00 Niall Douglas via Boost :

...

...

I'd therefore be happier with default construction giving uninitialised contents, or a default constructed T or E. No overloading state of E.

result and outcome have no E. I'm not talking about E or expected here. I'm talking specifically about result<T> and outcome<T>. That is, I'm trying to answer the question "Under the assumption that expected doesn't exist, what should the default constructor of result<T> do?"

Default constructing to an std::error_code of 0 is kind of stupid because "The operation failed: The operation succeeded", although one might, I suppose, make an argument in favor of constructing into a stupid state precisely because it's stupid.

I'd choose uninitialised bytes or default constructing T before default constructing E to a null error_code. As I've mentioned many times now, default constructed error_code is only by convention not an error, the unfortunate choice of the system_category by the C++ standard makes it not portable to assume a default constructed error_code is not an error.

If people did agree with me that a default trapping empty state is particularly useful in debug builds, the obvious choice for a release build default is uninitialised bytes. As Vicente mentioned, valgrind and the AddressSanitizer should catch misuse of those.

UB sanitizers will also catch the call to __builtin_unreachable(). If `result<>` and `outcome<>` adopted narrow-contract semantics, you could help the sanitizer by implementing observers like: ``` T const& error() const { if (has_error()) return _error; else { __builtin_unreachable(); // here goes any rescue semantics, if needed } } ``` Regards, &rzej;