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.