Re: [boost] [outcome] Possible extensions/changes to std::experimental::expected

...

...

I understand people like implicit constructors until they find that they don't want them here or there.

void f(optional<T>); T x; f(x);

Later on add void f(expected<T>); T x; f(x); // ambiguous :( This is fine. It's a compile time error. Writing f(expected<T>(x)) eliminates the ambiguity. Right, so being explicit from the beginning will avoid the need for change.

...

...

So T is a subset of two sets and then we need to be explicit. Been explicit from the beginning avoids surprises. This is just a compile-time surprise, so this is not all that bad. But you may get a run-time surprise

vector<T> x; void f(expected);

f(x); // are you aware that you are copying a vecotor? If people fail to use std::move, they should always assume a copy. Except when returning from a function.

f(std::move(x)) would do the right thing here I believe. So the implicit conversion of x will generate a copy. Would an explicit conversion help here? not too much, but at least the user will see that

Le 26/05/2017 à 17:57, Niall Douglas via Boost a écrit : the vector is passed as parameter to an expected before being passed to f.

...

Maybe no-one uses expected<T> as function parameter, but consider this:

expected g() { vector<T> v; // try to populate v; return v; // are you expecting a copy elision here? } This is definitely a concern for C++ 14 (not 17).

Are you sure copy elision in C++17 takes this case into account?

But I think end users get this problem with implicit conversion - it helps that recent clangs have a rich set of warnings when you do an inefficient return of a stack allocated object. So I don't think it as much a problem as others think. It will be great if you added in the documentation how do you solve the reported warnings ;-) I suspect that the solution is to access the stored value, isn't it?

...

...

Even if we wanted that expected is valid only if T is different from E, I believe the explicitness has added value. Throughout AFIO v2, I not only **always** return via make_valued_result or make_errored_result, I found myself specifying the return type too e.g. make_valued_result(s);

But imposing that on users so they have no choice ... that I don't agree with for a Boost library. Here we disagree as we already know. I am much less concerned with a STL type admittedly, there I'd live with always explicit construction.

Not me, I'm really concerned ;-) Vicente