On Tue, 22 Aug 2023 12:16:49 GMT, Johan Sjölen <jsjo...@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 After internal discussion I have come to the conclusion that this probably won't move forward, but if we have any external contributors who would like to voice their opinion I am happy to hear them. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15386#issuecomment-1688892278
