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

Subject: Re: [boost] [review] Review of Outcome (starts Fri-19-May)
From: Peter Dimov (lists_at_[hidden])
Date: 2017-05-15 11:33:30

Niall Douglas wrote:
> I'll tell you what though, if two more people strongly feel that 
> "basic_monad" and "monad_error" need to be renamed, I will do it. Please 
> people do suggest a better alternative name though.

basic_monad is an implementation detail, but monad_error is part of the 
interface.

> Similarly I intentionally sit on the fence with all the rest of Outcome: 
> it is up to the end user to choose the idiomatic style they prefer. That's 
> why the public API looks "heavy", but really it's just many syntax ways of 
> doing exactly the same thing.

The problem with this approach, apart from not sitting well with me 
personally, is that once the library enters wide use, you can no longer take 
any of these alternative APIs away without breaking code. It's better, in my 
opinion, to provide a minimal interface first, then add bells and whistles 
on an as-needed basis. I look at result<>'s reference documentation and all 
I can think of is that 2/3 of it isn't needed and 2/3 of that even consists 
of different spellings of the same thing.

I'd even remove value_or, there's nothing wrong with r? r.value(): def.

> During my ACCU talk, about half the audience really want implicit 
> conversion for T and E in Expected so you can skip typing make_xxx() all 
> the time. The other half want always explicit instantiation so that it is 
> impossible to create an Expected *without* using make_xxx() (BTW, Toronto 
> will be discussing enforcing this for std::expected i.e. to remove all 
> implicit conversion)

A legitimate fork in the road. What I'd do is enable conversion when 
unambiguous, otherwise require make_expected<T> and make_unpexpected<E>. But 
that's not what we're talking about here, because make_expected and 
make_unexpected will be present regardless of the decision to enable 
implicit conversion or not.

> Another defect in Expected in my opinion is having value return semantics 
> for .value_or(). You'll note Outcome's Expected has reference return 
> semantics for .value_or() which is a deviation.

I don't care for the pervasive &/&&/const&/const&& duplication 
(fourplication) very much myself, would return by value everywhere, but 
that's a matter of taste. Follows from the philosophy to provide the simple 
thing first, then complicate if need arises.