RFR: 8314644: Change "Rvalue references and move semantics" into an accepted feature

[Kim Barrett]

On Tue, 22 Aug 2023 12:16:49 GMT, Johan Sjölen <jsjolen at openjdk.org> wrote:

> Hi,
> 
> I'd like to propose that rvalue references and move semantics are now considered permitted in the style guide. This change would allow for move constructors to be written. This enables more performant code, if the move ctr is less expensive than the copy ctr, but also more correct code. For the latter part, look at "8314571: GrowableArray should move its old data and not copy it". Here we can avoid using copy assignment, instead using move constructors, which more accurately reflects what is happening: The old elements are in fact moved, and not copied.
> 
> Two useful std functions will become available to us with this change:
> 
> 1. `std::move`, for explicitly moving a value. This is a slightly more powerful `static_cast<T&&>(T)`, in that it also handles `T&` corectly.
> 2. `std::forward`, which simplifies the usage of perfect forwarding. Perfect forwarding is a technique where in copying is minimized. To quote Scott Meyers ( https://cppandbeyond.com/2011/04/25/session-announcement-adventures-in-perfect-forwarding/ ):
> 
>> Perfecting forwarding is an important C++0x technique built atop rvalue references.  It allows move semantics to be automatically applied, even when the source and the destination of a move are separated by intervening function calls.  Common examples include constructors and setter functions that forward arguments they receive to the data members of the class they are initializing or setting, as well as standard library functions like make_shared, which “perfect-forwards” its arguments to the class constructor of whatever object the to-be-created shared_ptr is to point to. 
> 
> Looking forward to your feedback, thank you.
> Johan

Some thoughts of mine, cribbed from that internal discussion. I'll preface by
saying that I'm not fundamentally opposed to permitting at least some uses of
move semantics in HotSpot code. I've thought about making a proposal in this
area myself. I haven't, in part, because I've seen very bad bugs in both
directions, so I keep waffling on the question. Also, I have to admit that the
size of the Josuttis book on move semantics (http://www.cppmove.com/) has kind
of put me off. I enjoyed reading it. But foisting it on other HotSpot
developers feels a bit much. And most of us will need some understanding of it
if any of us start using it.

A specific problem we currently have is that there are lots of classes with
default copy/assign constructors that really shouldn’t. At least some of those
probably ought to be movable but not copyable. Others probably ought to be
explicitly non-copyable, to prevent accidents.

Move semantics is an excellent tool for some problems, much better than
alternatives. Movable but not copyable objects is one example. Perfect
forwarding is another. Unfortunately, it also seems to be a very sharp tool.
(So totally in keeping with C++ culture. :) ) I think that if we do allow it,
we need to do so with eyes open, and that we will want to provide some well
thought out guidance, guardrails, &etc.

There are several problems we need to address with such a proposal. One is
when to define a class to be movable. I think that’s usually fairly easy to
decide. Another is when to enable use of move, and how. That’s mostly an issue
for holders of movable objects (containers, objects with movable data members,
&etc). That’s less easy. Still another is when to use std::move explicitly. My
experience is that’s often a source of really bad bugs. Though maybe less
often than our current frequently bogus default copy/assign.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15386#issuecomment-1690615432