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

[Julien Blanc]

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.
This :
- makes clear that you will store the value « as-is ».
- should be more efficient than copying the string
- still allows copying the string if the user needs to keep its own copy
of the data.
- cohabites well with a QStringView api

I do not see the benefit of a QString api vs a QStringView and a
QString&& api, which cover more use cases.

Regards,

Julien Blanc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20151020/4e226e1b/attachment.html>