RFR: 8234779: Provide idiom for declaring classes noncopyable

[Kim Barrett]

> On Nov 27, 2019, at 3:43 AM, Per Liden <per.liden at oracle.com> wrote:
> 
> Please don't add this :( I don't think this adds any value, it add another ugly macros I know I will never want to use. I'd much prefer to read real C++ instead of some macro that hides what's going on.

Not being explicit about copy functions or noncopyability (e.g. not
following the Rule of 3) can and has resulted in bugs.  C++ will
silently create the used functions with default definitions that
aren't at all what one wants in some cases.

The Rule of 3 makes it easer to read and understand code, because
certain classes of easily overlooked errors are prevented by the
compiler and simply cannot happen by design.  That's why it's a "rule"
in the wider community, even though not so much in HotSpot code, to
our detriment in my opinion.

The C++03 idiom of private declared but not defined copy ctor and
assignment operator is, so far as I know, the best mechanism available
for making a class noncopyable.  All other approaches I know of have
unpleasant side effects.

That idiom is rather wordy and indirect though.  In particular, it
is generally accompanied by comments indicating that this is to make
the class noncopyable, or that the declared functions are not defined
(not always with a reason, so that needs to be inferred).  Failure to
provide such comments means the reader may need to check for a
definition in order to determine whether that idiom is being used, or
whether the definitions are just not inline.

The proposed macro significantly reduces that wordiness.  Far more
importantly, it makes the intent entirely self-evident; there's no
need for any explanatory comments.

He C++11 idiom is slightly different, in that deleted definitions
should be used rather than leaving the operations undefined. That's
easily accomodated with this macro; a couple of small changes to the
macro and all uses are done.  (There is a benefit to making the
deleted definitions public with C++11, probably getting a better error
message, but that's chrome and can be improved lazily as code gets
touched.)

Much of software is about hiding details, e.g. abstraction.  (It would
be nice if C++ had a better mechanism for syntactic abstraction.)

So I disagree with the given rationale for objecting to this proposal.