[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