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

[Giuseppe D'Angelo]

On 19/06/2019 18:42, Matthew Woehlke wrote:
> On 18/06/2019 19.59, Giuseppe D'Angelo via Development wrote:
>> 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
>>> wheel?
>>
>> Why depriving? They can stay around, as-is. Current (and future) users
>> can still use them...
> 
> Mark wants to deprecate Q[E]SDP. That implies eventual removal, which
> absolutely *is* depriving users of something they were previously using.
> (Even just deprecating is requiring users to either a) stop using it,
> which again, is depriving them of it, or b) ignore deprecation warnings,
> which will not end well.)

I don't agree with the deprecation until we have a better alternative as 
public APIs. There's too much code using them.


>>> Here's a thought... how about, instead, just [...] mark the
>>> conversions-to-pointer deprecated.
>>
>> I don't see why people writing "if (d)" should now get deprecation
>> warnings and require const_casts to avoid them,
> 
> ...because, as previously noted, that code *detaches*, which is almost
> certainly not what you want!

I know that; I'm saying that 1) it's too late to change it (if we want, 
put it in QESDPV2); and 2) if (d) is supposed to be legitimate code to 
write, not something to trigger a deprecation warning.

> And no cast is required to fix it; just write `if(d.constData())`
> instead. (Also as previously noted.)

"Just" is a huge understatement. This is a workaround for an API flaw. 
Not something to put under "best practices" of any kind, nor an 
acceptable solution for a deprecation warning.

> Besides, I question the usefulness of implicit casts to pointer. The STL
> smart pointer classes don't have those, probably for a reason...

For the same reason implicit conversions are nitroglycerin:

AnySmartPointer p;
use(p + 42);


> Personally, I only ever use Q[E]SDP via a d-func and associated helper
> macros that make it clear if I'm detaching or not, and so (AFAIK) I've
> never had such "surprises".
> 
> Compare:
> 
>    // n.b. decltype(d) == QSharedDataPointer<MyClassData>
>    if (d->m_visible) // did this detach?
>    {
>      d->m_visible = false; // what about this?
>    }
> 
> - vs. -
> 
>    QTE_D_SHARED();
>    // n.b. decltype(d) == MyClassData const*
>    if (d->m_visible) // definitely did not detach
>    {
>      QTE_D_DETACH(); // definitely *did* detach
>      // n.b. decltype(d) == MyClassData*
>      d->m_visible = false;
>    }

This is interesting, but I'd like to find a solution which avoids 
enforcing the scope/block structure of the program. Compare that with 
QEDSP, which allows to be more "streamlined" (of course at the cost of 
const incorrectness):

   if (d->foo == foo)
     return;
   detach();
   d->foo = foo;
   d->bar = calc();


Note that proposing such macros is a case for deprecating QSDP/QESDP in 
favour of something else.


My 2c,
-- 
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...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4329 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190619/0773835a/attachment.bin>