Andre' (28 March 2024 15:22) asked: > What was _qs's life time from invention to deprecation? > A bit more than a year?
Yes: _qs was added in 6.2 (2021-03-04) and, in 6.4 (2022-03-21, when _s was added), declared deprecated from 6.8. Mistakes get made. We fix them as soon as we reasonably can after recognising they've been made. I very much doubt that _s and its peers will suffer a similar fate. They've already lasted twice as long as what they replaced. Friedemann Kleint (Thu, Mar 28, 2024 at 12:14:35PM +0100) had asked: >> Surely, the Foundation Team is in the process of creating instructive >> documentation on string theory? https://bugreports.qt.io/browse/QTBUG-77020 Hopefully soon. Andre' answered: > On a sarcastic day I might be tempted to suggest creating an RSS feed > for that. On the other days I'd say that's a two-liner: Recommend > QT_RESTRICTED_CAST_FROM_ASCII at least for non-library code (this > includes tests) and be done. That sounds like a fairly good TL;DR summary of one sane policy. A QT_RESTRICTED_CAST_FROM_ASCII how-to would improve it. While I'd generally encourage folk changing code to, as long as they're confident they know what's better, modernise string usage in the changed code, it seems unreasonable to require those fixing bugs to the choice of string representation to make unrelated changes to fix such preexisting details. Suggest it as a possibly worth-while drive-by, to be sure, but it shouldn't block their bug-fixes or feature development. I'm afraid any energy savings per run of CI, that could be made by mildly improving string usage, have to be offset against at least the (energy costs of the) extra CI runs * that must be made to integrate such modernisation changes, and * that'll be forced when other folks' subsequent changes follow the modern form after a modernisation, are picked back to before it and then fail to build until the author fixes them to be compatible with the older code-base. While that won't stop me modernising as part of cleaning up existing code, when I feel moved to do that, I'd encourage doing any such clean-up as a single comprehensive revision (of at least one whole test) rather than piecemeal, so as to reduce the number of extra CI runs due to at least the first of these. Of course, changes made as part of other work avoid those extra CI runs, so provide a path towards incremental improvement, when they fit naturally for those doing that other work. Eddy. -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
