On 21/08/2014 01:00 p.m., Peter Dimov wrote:
Agustín K-ballo Bergé wrote:
And, while I can grudgingly accept the argument that the class deriving > from noncopyable needs to decide whether to be trivially constructible > or not, in this case, it is not that class that makes the decision. All > classes deriving from noncopyable weren't trivially copyable with the > old implementation and are now trivially copyable.
True, it is a breaking change for classes relying on an implementation provided default constructor.
Huh. I must be missing something. The default constructor does not affect trivial-copyability: It only affects triviality:
I'm having a hard time deciding where this matters...
Perhaps not. After all, I was arguing that close to zero current uses of noncopyable are trivial. But you and Andrey were arguing the opposite, that making 'noncopyable' trivial is a feature. So... does it matter or does it not? :-)
That comment was about a trivial default constructor only. I fail to imagine a case where one has a default-constructible noncopyable thingy, and whether that constructor is trivial or not matters other than for the trait. In any case, I may have misrepresented my position. I do not know about what the common use cases of `noncopyable` are, and I'm not a user myself. My point is simply that trivially copyable is an orthogonal thing to copyable today, so `noncopyable` should not be concerned with it. If it turns out the definition of trivially copyable is wrong and it's changed, then `noncopyable` will be benefit from that change transparently.
As I see it, since trivially copyable does not imply copyable, it is irrelevant for `noncopyable`. Even when it sounds funny.
It would be irrelevant in a world in which all code carefully guards its is_trivially_copyable checks with is_copy_constructible. This is not that world.
I can't really argue about the potential for misuse of the language.
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. I have some low-level optimizations in mind as well, but I don't dare say they are fully conformant yet. I need to investigate more.
Whether this matters, I don't know. I wouldn't use `noncopyable` in C++11 code, and I stopped using it in C++03 code a long time ago because it would result in "error: undefined reference for blablabla" with absolutely no context on whether the copy attempt happens (not entirely `noncopyable`'s fault, but enough to make it useless for me).
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, so it would be fair for me to strike the "entirely" from my comment above. In any case, the end result was the same, after repeated occurrences of these unhelpful error messages I just replaced it with forcing compile time error messages where I could. Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com