Agustín K-ballo Bergé wrote:
My point is simply that trivially copyable is an orthogonal thing to copyable today, so `noncopyable` should not be concerned with it.
That view seems academic. As a practical matter, noncopyable should very much be concerned with trivial copyability. If classes derived from noncopyable have to not be trivially copyable, then noncopyable should be defined in a way that would make them not trivially copyable. Stated differently, the meaning of "X: private noncopyable" is not tied to the language definition of 'copyable' circa 2011. The 'copyable' term in 'noncopyable' is not the same as the 'copyable' term in C++11. Stated as yet differently, if the typical user who says "X: private noncopyable" wants to imply by that that X is not trivially copyable, then noncopyable ought to be defined in a way that makes X not trivially copyable.
I can't really argue about the potential for misuse of the language.
This is not misuse. It is a correct literal interpretation of the standard. If a class is trivially copyable, I can copy it with memcpy and get a copy. That's what trivially copyable means. We can be literal and we can be pragmatic, but switching from one to the other is not a consistent position.
But even if we constrain ourselves to abstract theory... what meaning do you give to TriviallyCopyable & ~Copyable? What does it imply?
Strictly speaking it implies TriviallyDestructible, which matters for example if you decide to have a specialization for a wrapper class for TriviallyCopyable types and let all special member functions be implicit. In that case for `noncopyable` you get a trivially destructible wrapper, while any attempt to copy or move it results in a compilation error.
That's not what I had in mind when I asked. I'm asking what it means - logically - for a type to be trivially copyable but not copy constructible; not what follows from the language definition, because I know that, but what are the intended properties of the class, or in other words, why would you design one. Not being copy constructible means that the class should not be copied. Being trivially copyable means that the class bytes can be copied with memcpy and the language guarantees that the result is a proper copy of the object. What is the intersection of these two? Who needs to design such a thing?
Interesting. Why would the copy being private not result in a compile-time error?
Why indeed? I guess it would have been a compiler bug, ...
The only case that comes to mind is when you copy the class inside its own member function. Which is, I suppose, a legitimate example in which a deleted copy is better than a private undefined one.