>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....@qt-project.org <development-bounces+martin.smith=theqtcompany....@qt-project.org> on behalf of Thiago Macieira <thiago.macie...@intel.com> Sent: Sunday, October 18, 2015 10:55 PM To: development@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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
