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

[Smith Martin]

>This API here simply cannot exist because the returned value would be a 
>dangling reference.

I don't understand. Implicit for using the QStringView data() function is knowing that once the QByteArray is set, it is never changed. Then the data() function is ok, isn't it?

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: Monday, October 19, 2015 9:38 PM
To: development at qt-project.org
Subject: Re: [Development] RFC: Proposal for a semi-radical change in   Qt      APIs taking strings

On Monday 19 October 2015 18:38:52 Smith Martin wrote:
> >Again, please try writing this method:
> Doesn't that example just mean there are some classes that can't have a
> QStringView API? A class should have a QStringView API if it can be used
> safely.

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;
};

This API here simply cannot exist because the returned value would be a
dangling reference.

Therefore, QStringView returns must be treated like references: only in
exceptional cases.

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