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

[Daniel D. Daugherty]

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

Thanks for the info. I appreciate the effort that it takes to dig up the details
on all these tool sets. If we could come up with tests of our classes that rely
on newer C++ features such that the tests are good enough to catch underlying
C++ errors, then I would be happier with those. Thanks for considering the
feedback.

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

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