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

[Marc Mutz]

On Tuesday 20 October 2015 01:08:31 Thiago Macieira wrote:
> 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.

That's because you castrate the uses too much :)

There are a ton of inlines types that would benefit, because they cannot be 
changed anyway.

If you look at uic or qdoc, you'll see QStringView use-cases pop up in every 
corner.

But mainly our impedance mismatch is that you focus on return values and I 
focus on arguments. I agree on the trickyness of the QSV result types, but 
there are always exceptions, some of which you and I mentioned, so I wouldn't 
go as far as saying (a). That would ban QXmlStreamReader, e.g.

n the function argument side of things I see no real reason to have anything 
but QStringView arguments, plus strategic QString&& ones. The only reason to 
so much restrict the use of QSV as arguments type is the wish to avoid QString 
deep copies, the fear of which you said you don't share.

So if deep copies loose their ineffciency myth, what reason remains to not use 
QSV in all functions taking QString?

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts