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

[Smith Martin]

>Return values must always be QString, never QStringView. Returning a view is
>like returning a reference and goes against Qt's library code policy.

But an assumption is the user manages the ownership of the underlying string, so it seems different. I'm rewriting the C++ parsing in qdoc. It calls a tokenizer that has a token()function that returns an enum value and a lexeme() function that returns a QString. It builds the QString for lexeme() each time, when it would be better to return a QStringView, since I know the text won't change. For the names that have to be saved, the QStringView can be passed to the tree node constructor, and only one QString gets built.

martin
________________________________________
From: development-bounces+martin.smith=theqtcompany.com at qt-project.org <development-bounces+martin.smith=theqtcompany.com at qt-project.org> on behalf of Thiago Macieira <thiago.macieira at intel.com>
Sent: Sunday, October 18, 2015 10:55 PM
To: development at qt-project.org
Subject: Re: [Development] RFC: Proposal for a semi-radical change in Qt        APIs taking strings

On Sunday 18 October 2015 21:27:31 Giuseppe D'Angelo wrote:
> That the proposal is that every single function currently taking a
> QString should instead be changed to take a QStringView instead, unless
> a few exceptional cases (for instance the function is used to store the
> string somehow, plus other cases under discussion). Similar case for
> return values. If that doesn't look like a radical change to you...

Return values must always be QString, never QStringView. Returning a view is
like returning a reference and goes against Qt's library code policy.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development