[Development] QUIP 6: removing top-level const from return types

[Olivier Goffart]

Am Dienstag, 23. Mai 2017, 11:17:32 CEST schrieb Ville Voutilainen:
> On 23 May 2017 at 12:00, Marc Mutz <marc.mutz at kdab.com> wrote:
> >> Maybe, but I have some questions: the review for removing top-level
> >> consts
> >> from QRegion says "It has no effect and inhibits move semantics." How
> >> does
> >> it inhibit move semantics? How is this even a SiC? What _positive_ impact
> >> do these changes have?
> > 
> > See Olivier's example:
> >    QPixmap pix;
> >    pix = splash.pixmap();
> > 
> > with
> > 
> >    const QPixmap pixmap() const;
> > 
> > calls the copy assignment operator, while with
> > 
> >    QPixmap pixmap() const;
> > 
> > it calls, as expected, the _move_ assignment operator.
> 
> Ok, yeah, I was using constructors, not assignment operators so I
> failed to see the
> issue.
> 
> So, we are doing this to improve performance of otherwise valid code,
> but not making this
> change doesn't make anything worse, right?

Someone could have written:

 const QPixmap (QSplashScreen::*hello)() = &QSlpashScreen::pixmap;

or

 static_assert(std::is_const<decltype(splash->pixmap())>::value);
 
But that's unlikely and just a theoretical construct. I'd say that the risk 
that this change breaks anything is less than for most of the other changes we 
do to the API, including adding functions to classes.