Subject: Re: [boost] [review] Review of Outcome (starts Fri-19-May)
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2017-05-17 00:13:28
On 17/05/2017 11:34, Peter Dimov wrote:
>> So why not "T get()"? That's much more consistent with other types.
>
> .get() is when you only have one thing to get; it's for one-element
> containers, where there's no ambiguity as to what is being got.
>
> expected<T, E> and friends have two; the value is .value() and the error
> is .error(), with their matching queries has_value() and has_error().
But by definition these are not treated equally. The value is the
expected thing (thus get() makes sense to retrieve it) and the error or
exception are the unexpected things (thus some other method). I don't
see any ambiguity there.
> It's not that get() is unacceptably wrong, but the
> value/has_value/error/has_error convention is legitimate and consistent.
Having "T value()" as the only API is fine, but seems a bit inconsistent
as that's not the common verb used by other types (in fact it's not even
a verb). (std::get is another argument in favour of this.)
Having "T value()" and "T get()" is ok (it's sort of like Boost Optional
that way) but it's a bit redundant and it would just make people
second-guess which one they should use, or if they're different in some way.
Having "T value()" and "void get()" is just bananas. Though for Niall's
proposed usage, perhaps "void ensure()" would make sense.
Regarding [[nodiscard]], I don't think either of these methods should
have that. Instead it should be the method that returns the expected<>
or outcome<> that declares its return value to be [[nodiscard]] (if it
wishes).
Though I recall another proposed library using some trick (possibly
involving rvalue-methods?) to ensure a compiler error if the return
value was uninspected without explicitly using [[nodiscard]].