Request for comments: D1155 "More implicit moves"

[Arthur O'Dwyer]

Attached please find the current draft of my proposal D1155 "More implicit moves."

Programmers expect return x; to trigger copy elision; or, at worst, to implicitly move from x instead of copying. Occasionally, C++ violates their expectations and performs an expensive copy anyway. Based on our experience using Clang to diagnose unexpected copies in Chromium, Mozilla, and LibreOffice, we propose to change the standard so that these copies will be replaced with implicit moves.
[...]
This feature has effectively already been implemented in Clang since February 2018; see [D43322]. Under the diagnostic option -Wreturn-std-move (which is enabled as part of -Wmove, -Wmost, and -Wall), the compiler performs overload resolution according to both rules — the standard rule and also the rule proposed in this proposal. If the two resolutions produce different results, then Clang emits a warning diagnostic explaining that the return value will not be implicitly moved and suggesting that the programmer add an explicit std::move.

This proposal is directly related to one of my CppCon 2018 talks: "RVO is Harder Than It Looks."

I'd appreciate any feedback that anyone has on the paper in its current state!  (And many thanks to Lukas Bergdoll for his excellent feedback already.)

–Arthur

[Barry Revzin]

I dunno why my messages keep getting deleted.

Anyway, attempt #3. The slicing example is not compelling and should go last, if it even needs to be present at all. Much more compelling are by-value sink arguments:

struct A {
A(std::string);
};

struct B {
B(std::unique_ptr<int>);
};

A eleven() {
std::string s;
return s; // copy
}

B twelve() {
std::unique_ptr<int> p;
return p; // error
}

Would be nice if those both compiled and moved. Also, would be worth it to ping Howard about the original restriction... it's from way back in N1952.

Also, as a formatting note... would suggest highlighting instead of bold. The bold doesn't really stand out.

[Ville Voutilainen]

This paper http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0527r0.html
is already in Core.

[Barry Revzin]

That paper seems orthogonal to this one. It doesn't address any of the examples here, as far as I can tell?

[Ville Voutilainen]

On 15 August 2018 at 02:14, Barry Revzin <barry....@gmail.com> wrote:
>> This paper
>> http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0527r0.html
>> is already in Core.
>
>
> That paper seems orthogonal to this one. It doesn't address any of the
> examples here, as far as I can tell?

Right; it's in the same problem space somewhat, but not quite the same.

[Howard Hinnant]

This is CWG 1579: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1579

and was accepted for C++14.

Howard

> --
> You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
> To post to this group, send email to std-pr...@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b2f16fed-730b-402c-bffb-eb4dc8f3ed69%40isocpp.org.

[Arthur O'Dwyer]

No, Barry's right. Both of his examples (try to) make copies instead of moving.

https://godbolt.org/g/uYgt7R

And I need to investigate why `-Wreturn-std-move` isn't triggering on that first example!

However, re "slicing isn't motivating": slicing was actually my original motivation for `-Wreturn-std-move` (and thus for the paper). My employer's codebase relies heavily on value-semantics plus inheritance plus RAII, like a `ListExpr` that is derived from `Expr` but has the same behavior w.r.t. ownership of the underlying resource. So slicing a `ListExpr` into a plain old `Expr` in a return statement is actually very common in our codebase. Come to my CppCon talk for more details! :)

On Tue, Aug 14, 2018 at 5:34 PM, Howard Hinnant <howard....@gmail.com> wrote:

This is CWG 1579:  http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1579

and was accepted for C++14.

Howard

On Aug 14, 2018, at 6:57 PM, Barry Revzin <barry....@gmail.com> wrote:
>
> I dunno why my messages keep getting deleted.
>
> Anyway, attempt #3. The slicing example is not compelling and should go last, if it even needs to be present at all. Much more compelling are by-value sink arguments:
>
> struct A {
>  A(std::string);
> };
>
> struct B {
>  B(std::unique_ptr<int>);
> };
>
> A eleven() {
>  std::string s;
>  return s; // copy
> }
>
> B twelve() {
>  std::unique_ptr<int> p;
>  return p; // error
> }
>
> Would be nice if those both compiled and moved. Also, would be worth it to ping Howard about the original restriction... it's from way back in N1952.
>
> Also, as a formatting note... would suggest highlighting instead of bold. The bold doesn't really stand out.
>
> --
> You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.

> To post to this group, send email to std-pr...@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b2f16fed-730b-402c-bffb-eb4dc8f3ed69%40isocpp.org.

--
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/eeLS8vI05nM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to std-proposals+unsubscribe@isocpp.org.

To post to this group, send email to std-pr...@isocpp.org.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/98C0A9E1-E6BB-4E21-BA9A-A88FD45E9440%40gmail.com.

[Howard Hinnant]

I never claimed clang was conforming. Try gcc.

Howard

> > To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.

> > To post to this group, send email to std-pr...@isocpp.org.
> > To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b2f16fed-730b-402c-bffb-eb4dc8f3ed69%40isocpp.org.
>
> --
> You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/eeLS8vI05nM/unsubscribe.

> To unsubscribe from this group and all its topics, send an email to std-proposal...@isocpp.org.

> To post to this group, send email to std-pr...@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/98C0A9E1-E6BB-4E21-BA9A-A88FD45E9440%40gmail.com.
>
>

> --
> You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.

> To post to this group, send email to std-pr...@isocpp.org.

> To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0L%2BL3Qw01JqTD338unRD6aFdG97cgAt-swkqdbVeVWypw%40mail.gmail.com.

[Barry Revzin]

On Tuesday, August 14, 2018 at 7:34:50 PM UTC-5, Howard Hinnant wrote:

This is CWG 1579:  http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1579

and was accepted for C++14.

Howard 

 

I disagree. That issue allows for trying moves first for more cases, but it still keeps the restriction (http://eel.is/c++draft/class.copy.elision#3.sentence-2), emphasis mine:

> If the first overload resolution fails or was not performed, or if the type of the first parameter of the selected constructor is not an rvalue reference to the object's type (possibly cv-qualified), overload resolution is performed again, considering the object as an lvalue.

CWG 1579 allowed this case to become a move:

struct A {
  A(std::string&&);
};

A f() {
  std::string x;
  return x; // move because of this issue
}

but not either of the examples I mentioned. 

[Howard Hinnant]

Thank you for the education! I had no idea the rules were this screwed up.

I was not strongly in favor, nor strongly against CWG 1579. My rationale is that the rules for implicit move should be easy to teach and remember. You have shown me that they are now far more cryptic than I understood them to be. We would have been better off without CWG 1579 than in this half-way-there twisty maze of passages that all look alike.

struct A
{
A(std::unique_ptr<int>) {}
};

struct B
{
B(std::unique_ptr<int>&&) {}
};

A
test1()
{
std::unique_ptr<int> p;
return p; // fails
}

B
test2()
{
std::unique_ptr<int> p;
return p; // ok
}

Howard

> --
> You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
> To post to this group, send email to std-pr...@isocpp.org.

> To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/25a4f822-e9f3-47ce-9458-d3dd6b242421%40isocpp.org.

[Arthur O'Dwyer]

On Tuesday, August 14, 2018 at 7:35:24 PM UTC-7, Howard Hinnant wrote:

Thank you for the education!  I had no idea the rules were this screwed up.

Right up there with ADL. ;)

I'm attaching a new draft revision of D1155 "More implicit moves."  This revision prominently incorporates Barry's "by-value sink" examples — and I decided to give the four classes of examples in the same order as their controlling phrases appears in N4762, which means Barry gets his wish and "slicing" moves to the very bottom of the list. :)

Based on feedback from David Stone, I've also shown the alternative wording that would be proposed on the (IMHO good) assumption that P0527 is shortly to be adopted by CWG.

Thanks to Howard for (even accidentally :)) reminding me to check GCC's behavior. It turns out that GCC 5.1+ actually do the move in Barry's examples, even though Clang doesn't do the move... and honestly I'm not 100% sure whether the Standard requires us to or not!  (The crux is what does the Standard mean by the phrase "the selected constructor." P1155 deletes that troublesome phrase, meaning that the move will definitely be required if we adopt P1155. Which is exactly what we want, IMHO.)

–Arthur

[Barry Revzin]

On Wednesday, August 15, 2018 at 6:47:02 PM UTC-5, Arthur O'Dwyer wrote:

I'm attaching a new draft revision of D1155 "More implicit moves."  

Looks great to me!