[Development] Qt 5 types under consideration for deprecation / removal in Qt 6
giuseppe.dangelo at kdab.com
Wed Jun 19 01:59:57 CEST 2019
On 18/06/2019 23:27, Matthew Woehlke wrote:
> 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
Why depriving? They can stay around, as-is. Current (and future) users
can still use them...
> 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
>>>> 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.
I don't see why people writing "if (d)" should now get deprecation
warnings and require const_casts to avoid them, when it's absolutely not
"their fault" for doing something unreasonable. Besides, as mentioned,
the real deal is operator->.
My 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