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. _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development