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.dang...@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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
