[Development] QList

[Giuseppe D'Angelo]

Il 27/03/2017 17:46, Thiago Macieira ha scritto:
> 
>> Another point that hasn’t been discussed yet, is how to handle QStringRef.
>> In my opinion, we should deprecate it, but it’s used quite a bit in some
>> parts of our API (QXmlStreamReader comes to my mind). It would be good to
>> also think about how to solve that case. QStringRef has a pointer to a
>> QString, but does not increase the refcount of it. So it looks like we can
>> simply make it an alias for QStringView. That would break the
>> QStringRef::string() method (which we should probably deprecate in 5.10 to
>> prepare for the change), but everything else should stay compatible.
> We can't... I tried that a while ago and it broke QXmlStreamReader and other 
> places badly. The issue is that they expect QStringRef to continue to be valid 
> after mutating the QString it was bound to. That works because of the pointer 
> to the QString, as opposed to a pointer to the data. And that's just what I 
> found by after changing QStringRef a few years ago to be like QStringView 
> today and simply running Qt Creator.
> 
> We can port away from QStringRef and into QStringView as we go by and where 
> it's safe. But unless we're willing to refactor some code substantially. 
> Unfortunately, it's very likely we can't begin this work now as it would break 
> the QStringRef API and thus be BIC/SIC.
> 
> So, yes, deprecate, but we'll have to carry QStringRef for some time, like 
> QRegExp.

QRegularExpressionMatch has a similar problem: it currently stores a
copy of the subject string passed to
QRegularExpression::match(QString/QStringRef). People are relying on
this behaviour, including its own autotests; for instance, this works:

>     QRegularExpression re("\\d+");
>     auto m = re.match("foo123bar"); // stores a copy
>     assert(m.captured(0) == "123"); // safe -- extracts substring from internal copy

Questions:

1) Should this behaviour be deprecated and eventually changed? How to
make users aware of this behaviour change?

2) Suppose we add right now a match(QStringView) overload, should it
still return a QRegularExpressionMatch or a new class with similar API?
If it still returns a QREM, what would QREM::capturedRef(N) then return
for a match over a string view?

(Trying to find the path of least breakage)

Cheers,
-- 
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - Qt, C++ and OpenGL Experts

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4007 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170403/1f55e42e/attachment.bin>