Re: [boost] Outcome v2 is feature complete

Subject: Re: [boost] Outcome v2 is feature complete
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-07-11 15:35:53

>> I don't understand. variant<...> knows exactly what the alternatives are.
> 
> It doesn't know what they mean though. Doesn't know that T1 is the value
> and T2 is the error.

Neither do result/outcome. "value" is simply the first item, "error" the
second item.

It's the policy class which gives meaning. And it can choose, legally,
to give them no meaning. For example, one of the policies simply calls
std::terminate for everything :)

(and yes, I may tighten this laxity as use experience is accumulated)

>> It surely would be straightforward to look at some Arg&&... sequence
>> and do std::is_constructible<X, Arg&&...> matching against all
>> possible variant states.
> 
> The one-argument variant constructor performs overload resolution across
> all alternatives and chooses the best match (if one exists.)
> 
> This makes it possible for it to sometimes surprise the user with its
> choice.
> 
> Extending this to multiple arguments would be possible in principle, but
> it's not that straightforward as you make it seem. It's not just a
> matter of checking is_constructible. You need to choose the best match.

I was just about to tell you that you are wrong, and I went to
http://en.cppreference.com/w/cpp/utility/variant/variant only to see
that you are correct.

Outcome does not do this, the converting constructors disable themselves
if there is any ambiguity in what to construct. We don't do overload
resolution, if we had to, we fail to compile.

I am in fact quite surprised - perhaps even shocked - that variant does
that. I'd call that a dangerous behaviour. Anything implicit, hidden,
and non-obvious like that is an unwise design choice. Better to make the
programmer spell out intent when there is a chance of ambiguity.

>> The fact they don't do it I surely think is a deliberate and
>> intentional design choice for some hopefully good reason.
> 
> I'm not so sure.
> 
> `variant` is very tricky to specify, and from a certain point on, people
> were so tired of the endless discussions that they shot any new
> suggestion down regardless of merits if it had the potential to generate
> further controversy.

:(

> I don't remember this even being proposed, but had it been proposed, it
> would probably have been rejected summarily without any deliberation,
> because it's pretty subtle.

:( :(

This is why we don't rush design-by-committee things into the C++
standard. I'm really shocked about that overload resolution design
decision. That's such an unwise choice given the available alternatives.

Anyway I think you've persuaded me on issue #56. Great idea on the
two-arg form.

Niall

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