[Development] r-value references in API (was: RFC: Proposal for a semi-radical change in Qt APIs taking strings)

[Koehne Kai]

> -----Original Message-----
> From: development-bounces+kai.koehne=theqtcompany.com at qt-project.org
> [mailto:development-bounces+kai.koehne=theqtcompany.com at qt-project.org]
> On Behalf Of Bubke Marco
> Sent: Thursday, October 15, 2015 10:14 PM
> To: Thiago Macieira <thiago.macieira at intel.com>; development at qt-
> project.org
> Subject: Re: [Development] r-value references in API (was: RFC: Proposal for a
> semi-radical change in Qt APIs taking strings)
> 
> On October 15, 2015 17:58:27 Thiago Macieira <thiago.macieira at intel.com>
> wrote:
> 
> > On Thursday 15 October 2015 07:34:30 Koehne Kai wrote:
> >> > -----Original Message-----
> >> > [...]
> >> >
> >> > >BTW: functions storing a passed QString as-is should provide a
> >> > >QString&& overload, and that might be a good idea even when
> >> > >otherwise using QStringView only.
> >> >
> >> > Yes, agree with this.
> >>
> >> I guess this advice is not only for QString arguments though (from
> >> 5.7 onwards). Which other types should get an && overload?
> >>
> >> Does API exposed via Q_PROPERTY/ QML benefit from an r-value
> >> reference overloads, too?
> >>
> >> I think it's a good idea to create some recommendations for 5.7 now,
> >> before everyone develops his own rules ...
> >
> > I didn't address this in my reply to Marc...
> >
> > This part of his proposal falls apart the moment that the API function
> > calls something else to do the processing. Now you need to duplicate
> > almost every code path from the user-facing API down to the processing
> > of the data. And when the API has two data types, now the permutations
> explode...
> >
> > rvalue refs only make sense for very simple sink functions. Not even
> > most QString overloads would be able to do it.

Ok. I'll try to rephrase this then to come up with an easy advice:

'''
Consider providing an && overload for simple setter functions that take a not trivially copyable value type as an argument (e.g. QString, QVector ...). 

For example:

void setName(const QString &name) {  m_name = name; }
void setName(QString &&name) { m_name = std::move(name); }
'''


Anyhow, we could also decide that, now that we expect C++11 to be available, we can also rely on move semantics and only use pass-by-value. This was actually suggested by Olivier in 2012 (!), see http://permalink.gmane.org/gmane.comp.lib.qt.devel/3484 :

Lars replied back then though that this "moves the code required for making the copy for the cases where the compiler can't optimize it away to the caller, ie. from a shared to a non shared location. This can increase the total size of the code generated." (see http://permalink.gmane.org/gmane.comp.lib.qt.devel/3502).

Olivier then retracted the proposal. Should we reconsider it though, now that we can expect C++11 from 5.7 onwards? Or does the code size increase still hold? Shall we do some more experiments with this?

> I see the move semantics as a good way for ownership transfer. It is a much
> better ideom than sharing because you easily ask for țrouble if you share.
> Working on the same data structure from many processors is very inefficient. So
> the move semantics would make it clear that you should not share. Otherwise if
> you want process read only data you can use const references. I think the new
> model is much better than all type of pointers. The problem with pointers is that
> they can be null and you should check in interfaces but semantically you have no
> description in your concept that the structure is not there.

I understand that there are other uses of r-value references, but for the moment I'd personally like to keep the discussion focused on simple setter functions, because they're so common.

Regards

Kai