On Monday 19 October 2015 20:31:53 Bubke Marco wrote:
> On October 19, 2015 21:38:51 Thiago Macieira <thiago.macie...@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
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
