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

[Matthew Woehlke]

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