[Development] How qAsConst and qExchange lead to qNN

Edward Welbourne edward.welbourne at qt.io
Mon Nov 7 18:51:57 CET 2022


Volker Hilsheimer (7 November 2022 16:51) wrote:
> The open question is whether and when we should deprecate such a
> stop-gap 1:1 reimplementations of std functionality. How to deprecate
> is now well documented, but the wiki starts with the process of doing
> so once we concluded that we shall. It doesn’t give us any guidance
> yet on how to come to that conclusion.

And, just to be clear, that omission was entirely deliberate.  When I
wrote [[Deprecation]], I was quite sure we did not have a consensus on
the answer to that question, so what I wrote takes no position on the
controversy.  On the one hand, the benefits of getting rid of old cruft
argue for deprecating anything for which there is now a better way to do
whatever it was there for; on the other hand, disruption to users of Qt
is unwelcome, arguing for only deprecating anything when its use is
actually apt to cause harm (e.g. the old API incorporates a design bug).

For Qt to remain relevant in the rapidly-evolving C++ landscape, it
needs to change; but one of its strong selling-points has long been its
conservatism in API and ABI, that lets working code keep working.

There is thus an inevitable tension between "move forward, leaving the
past behind" and "if it ain't broke, don't 'fix' it",

	Eddy.


More information about the Development mailing list