[Development] Qt 5 types under consideration for deprecation / removal in Qt 6
mwoehlke.floss at gmail.com
Wed Jun 19 21:51:49 CEST 2019
On 19/06/2019 15.03, Giuseppe D'Angelo via Development wrote:
> On 19/06/2019 18:42, Matthew Woehlke wrote:
>> 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.
Likewise. I guess we're in agreement here?
>> On 18/06/2019 19.59, Giuseppe D'Angelo via Development wrote:
>>> On 18/06/2019 23:27, Matthew Woehlke wrote:
>>>> 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.
Well, *I* can live with leaving it alone. After all, *I* am not misusing
Q[E]SDP ;-). Marc will be unhappy, I suppose.
>> 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".
>> // n.b. decltype(d) == QSharedDataPointer<MyClassData>
>> if (d->m_visible) // did this detach?
>> d->m_visible = false; // what about this?
>> - vs. -
>> // 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;
> Note that proposing such macros is a case for deprecating QSDP/QESDP in
> favour of something else.
I'm... not sure how that follows?
More information about the Development