Re: [boost] Outcome v2 is feature complete

...

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 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/