On Sat, Dec 8, 2018 at 1:33 PM Ville Voutilainen <ville.voutilai...@gmail.com> wrote: > On Sat, 8 Dec 2018 at 20:05, Ville Voutilainen > <ville.voutilai...@gmail.com> wrote: > > > > New compiler releases will usually include new warnings that require > > > some code modification to accommodate. Why is this one particularly > > > problematic? > > > > I don't think it's any more problematic than any other warning that > > introduces new errors for fools that build with -Wall and -Werror. > > But considering that those errors are false positives, and that > > turning them off will in some cases require writing boiler-plate > > (defaulted assignments), I would merely prefer having another release > > round to get fixes for my codebase out in the wild. > > For what it's worth, I find it unfortunate that this deprecation and its > resulting warnings end up > making the decision on whether a "rule of 5" must be followed; correct code > needs to be adjusted > to cope with a fairly stylistic matter, with false positives and all.
I don't see it as a stylistic matter. If you need a user-provided copy constructor to get proper copy semantics for a class, you almost certainly need the same thing for copy assignment. This was too noisy for destructors, for which it's fairly common to define a virtual destructor just to make a class polymorphic, not because there are significant destruction semantics. But I don't see a similar argument for copy constructors: in your example, there was no need for QVariant::Private to define a copy constructor, and that seems like a situation where a warning is reasonable, even if the code is in fact correct. Jason
