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

[Thiago Macieira]

On Monday 19 October 2015 20:31:53 Bubke Marco wrote:
> On October 19, 2015 21:38:51 Thiago Macieira <thiago.macieira at intel.com> 
wrote:
> > Right. I'm simply saying that "if it can be used safely" is very, very
> > restricted.
> > 
> > Suppose you have in v1:
> > 
> > class Foo
> > {
> > 	QString m_data;
> > public:
> > 	QStringView data() const;
> > };
> > 
> > Which looks fine and works without dangling references. Then in v2, you
> > need to do this:
> > 
> > class Foo
> > {
> > 	QByteArray m_data;
> > public:
> > 	QStringView data() const;
> > };
> 
> How can you make a QStringView from a byte array? 

That's exactly the point. It was a tricky question and this is exactly the 
gotcha. You cannot. Therefore, the API must not be permitted, save for 
exceptional cases where you know the internal backing will NEVER EVER change 
(until the next source compatibility change, at the soonest).

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.

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