[Development] Qt 5 types under consideration for deprecation / removal in Qt 6

[Giuseppe D'Angelo]

On 18/06/2019 22:56, Alberto Mardegan wrote:
> On 18/06/19 10:43, Mutz, Marc via Development wrote:
>> On 2019-06-18 08:18, Alberto Mardegan wrote:
>>>
>>> Adding a const bool operator to QSharedDataPointer would solve the
>>> problem, wouldn't it?
>>
>> And (silently) break code that relies on the current behaviour, yes.
> 
> Well... Expecting the data to detach on an `if (d)` check seems worth
> incurring into a breakage :-)
> But I certainly cannot exclude that there is some code out there which
> happens to work exactly because of this implicit detach, so it might be
> better not touch this, after all.

When you read code like this, how can you be not sure that touching ANY 
behaviour isn't going to break it?

> https://code.woboq.org/qt5/qtbase/src/corelib/io/qprocess_p.h.html#_ZN26QProcessEnvironmentPrivateC1ERKS_
> https://code.woboq.org/qt5/qtbase/src/corelib/io/qprocess_p.h.html#_ZN18QSharedDataPointer6detachEv


> I think you are overestimating the lock-in, here. The API surface of
> these classes is relatively small; they have been used for over a
> decade, with no major complaints. Yes, there are some issues, in some
> places they are badly designed, but during these years the problems have
> been noticed and now we have the chance to address them (with a
> replacement as your proposed one, for example).

It's very hard to know when to make such a call. These classes are so 
low level that _any_ behaviour will be observed and relied upon. Just to 
make an example, what happens if tomorrow we're not satisfied with the 
way we're handling move semantics for pimpled value classes and we want 
to change it?

Just 2 c,
-- 
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4329 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190619/33a51ede/attachment.bin>