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

Subject: Re: [boost] [outcome] How to drop the formal empty state
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2017-05-25 16:52:10

2017-05-25 17:14 GMT+02:00 Niall Douglas via Boost <boost_at_[hidden]>:

> >> 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<T, E>
> > 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<T,
> > E> 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;