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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk