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

[Thiago Macieira]

On Monday 19 October 2015 06:10:41 Smith Martin wrote:
> >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. 

Are you talking about a class that operates on user-provided data?

In that restricted scenario, it might make sense. The point I'm trying to make 
is that returning a non-owning copy means that something else must own the 
data. That's what goes against the library code policy.

Example:

	QUrl url;
	QStringView query() const;

It's not possible to write the query() function.

> 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.

Good, but qdoc is not a library so it's not subject to the library code 
policy.

> For the names that have to be saved, the
> QStringView can be passed to the tree node constructor, and only one
> QString gets built.

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