[Development] Qt 5 types under consideration for deprecation / removal in Qt 6
giuseppe.dangelo at kdab.com
Wed Jun 19 01:13:27 CEST 2019
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?
> 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...
Size: 4329 bytes
Desc: S/MIME Cryptographic Signature
More information about the Development