[Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

[Thiago Macieira]

On Tuesday 20 October 2015 10:06:28 Julien Blanc wrote:
> Le lundi 19 octobre 2015 à 16:08 -0700, Thiago Macieira a écrit :
> > So the summary of QStringView is:
> >  a) never used as return type
> >  b) used only as a parameter if the function processes the data and never
> >      stores it and will never, ever store it (lazy processing)
> >  
> >  c) for existing API, needs to be overloaded with QString
> > 
> > I'm not buying the cost/benefit ratio.
> 
> I don’t get b) statement.
>
> If you need to store it, as a QString, and you can afford to expose that
> to the user, then i think it’s better to provide a QString&& overload.

QString&& won't match a regular lvalue.

	QString s = "foo";
	function(s);

[and even if it did, it would be wrong]

But this would compile:

	function(QString(s))

because it now creates a copy before passing to the function. That is, you 
create a copy that you're giving ownership of.

I don't think I want this kind of API. It's too confusing.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center