Subject: Re: [boost] [outcome] How to drop the formal empty state
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2017-05-26 06:41:14
On 26/05/2017 17:33, Vicente J. Botet Escriba wrote:
> std::experimentall:expected<T,E>::error, doesn't throws. I don't see
> a use case where we want to retrieve an error without checking
> before. Maybe you have a case.
Perhaps unit tests, where you're expecting an error but the code
unexpectedly succeeds.
Also as in the case above, when you forget that an empty state exists:
result<T> r = something();
if (r.has_value())
{
do_something(r.value());
}
else
{
log(r.error()); // oops, r might be empty
}
I dislike gratuitous UB, and Niall assures us that optimisers will
discard a double check so it should be reasonably cheap.
> Le 26/05/2017 à 01:36, Gavin Lambert a écrit :
>> I don't like the idea of a default-constructed T because T is not
>> always default-constructible, and this makes it inconsistently behaved
>> for different T and makes it harder to use uniformly in containers,
>> especially in generic code.
For the record, not having a default constructor at all also makes it
harder to use in containers, so I don't like that either. Though it's a
weaker dislike than my dislike of a default-constructed T or E.
>> I don't like the idea of a default-constructed E because by convention
>> (even if not quite in fact as Niall has pointed out -- though I've yet
>> to see a platform where a 0 error code *didn't* mean success, other
>> than cases where the formal type is int but is actually used as bool)
>> the default-constructed error_code means "no error", and this is
>> heavily reinforced by its operator bool semantics.
>>
>> I do like the idea of a non-default-constructed error code, because
>> failure to initialise the result does seem like an error to me. Niall
>> points out that this is harder to detect and treat specially in code
>> but I don't agree with that; as long as a suitably unique error code
>> is used then a simple assert in the error path would pick it up, no
>> problem.
>>
>> If the consensus is that an initial non-default error code is not
>> satisfactory, then a formal empty state seems to me like the least
>> worst alternative. I just know that it's going to bite someone at
>> some point.
>
> If we don't provide a default constructor for expected<T> we could be
> forced to use optional<expected<T>>.
>
> This allows to don't pay for this empty state when we don't need it. The
> problem is that we are paying more than needed when we need it.
>
> We have two options:
> * we specialize optional<expected<T,E>>
> * we rename the intended specialization xxx<T> is similar to
> optional<expected<T>>. xxx could be outcome::result or optional_expected
I'm not entirely sure how this relates to what I was saying.
At least in terms of storage, the current implementation of empty state
is presumably free (it should be no more expensive to internally store a
variant<none_t, T, E> than a variant<T, E>). And it's currently
required to exist due to exception guarantees (and possible
noexcept(false) move constructors).
I don't think that T should be restricted to noexcept(true)-movable
types only, as this prevents using it with C++03 non-POD types (that
have a copy constructor but lack a move constructor), which are still
likely to be widespread in codebases (although perhaps less common as
return values).
Given that, from the sounds of it an empty state does need to exist in
the implementation. Where it sounds like Niall and you differ is
whether that state should be exposed to the user. I think if it's there
anyway then it probably should be, since this enables useful behaviour
(such as storing in containers and using that state as "method not
called yet", implying that the empty state should be the
default-constructed state).
If it turns out that the empty state is not needed by the
implementation, then a non-default-constructed-E seems like a better
default value, at least for Outcome where E is a known type. (It's a
bit harder for Expected.)
Another consideration is that regardless of default construction or not
is that you need to decide what an expected<T, E> will contain if
someone moves-from it (directly). Is it now formal-empty or does it now
contain a moved-from-T or moved-from-E? Or does it contain a
moved-from-variant<none_t, T, E> (if that's different)?
The return type of value() plays a role here as well. If it returns by
value, then you can probably pick whatever you like. If it returns by
reference, then the caller can now move-from the internal T and ensure
it will be in the has-a-moved-from-T state, not the empty state. (Which
may or may not be desirable, but implies that moved-from is not the same
as empty, which might surprise users of smart pointers.)
(Returning by reference also disallows possible future storage
optimisations from nested variant merging, as mentioned in another thread.)