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

Subject: Re: [boost] [review] Review of Outcome (starts Fri-19-May)
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-05-18 15:16:40

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.

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

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

Thoughts?

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/