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

...

...

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?

I am not up to date with C++ 17 yet. But assuming http://en.cppreference.com/w/cpp/language/return#Notes is correct: "If expression is an lvalue expression and the conditions for copy elision are met, or would be met, except that expression names a function parameter, then overload resolution to select the constructor to use for initialization of the returned value is performed twice: first as if expression were an rvalue expression (thus it may select the move constructor or a copy constructor taking reference to const), and if no suitable conversion is available, overload resolution is performed the second time, with lvalue expression (so it may select the copy constructor taking a reference to non-const). The above rule applies even if the function return type is different from the type of expression (copy elision requires same type)" ... then yes, 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 don't think the right place for telling people how to write warnings-free C++ is Boost documentation. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/