Re: [boost] [review] Review of Outcome (starts Fri-19-May)

Subject: Re: [boost] [review] Review of Outcome (starts Fri-19-May)
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2017-05-18 21:17:55

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

> On 17/05/2017 00:25, Gavin Lambert via Boost wrote:
> > On 16/05/2017 13:50, Peter Dimov wrote:
> >>> Surely this must also throw if f1_impl() can produce an error outcome
> >>> and thus might not contain an X?
> >>
> >> Yes of course, the examples are deliberately identical semantically, one
> >> uses "void get()" and the other uses "T value()". I prefer the second.
> >
> > Future uses "T get()".  This is established standard.
> > Smart pointers use "T* get()", which is equivalent to the above.  Also
> > standard.
> > Boost Optional uses "T& get()" (although also provides value(),
> > presumably for standard compatibility).
> >
> > Std Optional uses "T value()".  This is either still experimental or
> > approved for C++17; I'm not entirely sure how far along that is.
> >
> > The different interfaces of the above seem unfortunate (and Std Optional
> > seems incorrect in this regard to me).
> >
> > So why not "T get()"?  That's much more consistent with other types.
>
> Outcome provided only get() until last January when I added an Expected
> implementation.
>
> I have always felt that "get()" implied a potentially blocking operation
> somehow. Something about the word.
>
> My main rationale for choosing get() over value() was simple: the former
> is two characters less to type. Other than that, I feel unbothered as to
> which is better, and as you notice in the submitted library I provided
> both and pushed which to choose onto end users.
>
> I'm getting the feeling that that isn't considered a good a idea by
> reviewers so far, and you all want me to choose one, and not use .get()
> for an operation which doesn't return a value. .ensure() has been
> suggested for this.
>
> So are you happy or unhappy with this plan:
>
> 1. .get(), .get_error() and .get_exception() go away.
>

Yes.

>
> 2. .ensure(empty|value|error|exception) will perform the default actions
> of calling the observer function for that state, but not return that state.
>

Weak yes. - I am not sure why you need this fancy syntax.

>
> Note that empty, value, error and exception are already constexpr
> variables in the outcome namespace used for tagging.
>
> Thoughts?
>

Also, get rid of `is_ready()` if it does the same thing as `empty()`. And
maybe `is_empty()` would be less ambiguous: word "empty" is also a verb in
english.

Regards,
&rzej;