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

Mutz, Marc marc at kdab.com
Wed Jun 19 07:34:02 CEST 2019


On 2019-06-18 22:56, Alberto Mardegan wrote:
[...]
> if (d)

It's not if (d) which I expect to be used for detaching, but just the 
bool operator itself, if only as a short-cut to d.detach().

[...]
> Sure, it is possible that some new issues will be found after the Qt6
> release, but given the size of these classes, and the fact that we have
> more than a decade of experience using them (or a very similar API), 
> how
> likely is it that we screwed things up?
> If a new bug should be found, that hasn't surfaced in all these years,
> it's going to be a very, very minor issue.
[...]

I'm not concerned about bugs. I'm concerned that making Qt's pimpl_ptr 
public API constrains how Qt itself is implemented. Sure, we can add yet 
another pimpl_ptr and make that public again, by the same rationale. But 
what purpose do four different Qt pimpl_ptrs serve, which all need to be 
supported? That makes no sense. We had the same issues with QSharedData, 
btw. And since that was public, we had to introduce QtPrivate::RefCount.

Thanks,
Marc



More information about the Development mailing list