On 18/06/2019 03.43, Mutz, Marc via Development wrote: > BTW: this is the proposed replacement of QSDP/QESDP for Qt-internal use: > https://codereview.qt-project.org/c/qt/qtbase/+/115213 and no, it will > most certainly _not_ be public API again. It's the fact that these > implementation details of Qt, QSDP and QESDP, are public, that prevents > us from fixing them. I will not be part of another such lock-in.
So... to be clear, your plan is to deprive Qt users of a (mostly) perfectly good wheel, that *is* being used by said users, and instead tell all of those users that they need to go (individually) reinvent the wheel? On 18/06/2019 03.43, Mutz, Marc via Development wrote: > On 2019-06-18 08:18, Alberto Mardegan wrote: >> On 05/06/19 01:39, Kevin Kofler wrote: >>> Mutz, Marc via Development wrote: >>>> and produces surprises such as >>>> https://codereview.qt-project.org/gitweb?p=qt%2Fqtbase.git;a=commit;h=96dc9a19ae11ca140d681f0e2605b5f4b953e581 >>> >>> My existing QSharedDataPointer code always checks truth with if >>> (d.constData()) and never if (d). >> >> 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. Here's a thought... how about, instead, just add that operator bool, give it the *current* behavior, and mark *it* (and *only* it) deprecated. Or, even, just mark the conversions-to-pointer deprecated. Don't punish everyone that is using these classes *correctly* because of some few places that aren't. -- Matthew _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
