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".
>>
>> 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;
>> }
>
> Note that proposing such macros is a case for deprecating QSDP/QESDP in
> favour of something else.
I'm... not sure how that follows?
--
Matthew
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
