[Development] QList

[Lars Knoll]

> On 28 Mar 2017, at 07:01, Thiago Macieira <thiago.macieira at intel.com> wrote:
> 
> On segunda-feira, 27 de março de 2017 14:53:05 PDT Giuseppe D'Angelo wrote:
>> Why should it bad if what you want return is precisely a "const
>> reference" over QString-like data? Isn't that the whole reason why we
>> have functions returning QStringRef right now (lacking a QStringView)?
>> (And also the reason why QStringView itself returns QStringViews?)
> 
> The functions returning QStringRef are not a good practice. They are bad API 
> in the first place, so please don't make the situation worse.

I agree in general, but there are valid exceptions. Parsers are one of those places where returning a QStringView with a documented lifetime (e.g. until your next call into the parser) is IMO a valid thing to do (since performance is critical here).
> 
> Now, replacing QStringRef with QStringView may be acceptable, as it makes the 
> problem not much worse. But at least in the case of QXmlStreamReader, it does, 
> so that won't work.

I guess that’s because of some issues in how the XmlStreamReader allocates (or re-allocates) it’s string. We should probably simply try to see how we can fix the implementation instead of saying that we can’t change the API to use QStringView.
> 
>> Example of use case: a tokenizer operating over QString-like data,
>> returning each token as a QStringView, with no memory allocations --
>> possibly even noexcept (narrow contract on the source string). Why would
>> I want to return QStrings for this use case and super-pessimize it?
> 
> Tht's probably acceptable. We need to study each case in a case-by-case basis.
> 
> Rule of thumb is to return QString.

By default, return values should be QString, I agree. Returning QStringView exposes more internals of the class. It does make sense in certain use cases though.

Cheers,
Lars