That's why we have per-feature defines you can choose from (QT_NO_QPAIR, QT_NO_CONTEXTLESS_CONNECT, QT_NO_FOREACH, QT_NO_KEYWORDS). That's what I was proposing.
The number of QT_NO_FOO you have to type to be somewhat safe from your own stupidity is clearly getting out of hand, as we can already see from this statement alone. In QML we also have individual pragmas for all the individual practices, and it's not sustainable. That's where my suggestion about version-based profiles comes from.
In addition, however, a preprocessor define won't cut it in the case of AutoText. The default textFormat for e.g. QLabel lives in qlabel_p.h which never sees a user #define. It's baked in when _Qt_ is compiled.
If you want to adopt "best known practice as of 6.14", you get to adopt it wholesale. But each and every practice should be individually controllable. I'm not a fan of this technique, especially because people tend to think of the *application* choice, when it's really a per-TU choice. The application's choice does not translate to third-party libraries or plugins it loads.
Yes, you can only control the code you actually compile. The scoping needs to be clearly documented.
I personally don't look at those options. Do we even have them? I just ignore those changes because I believe they are a flawed design. If anyone asked my opinion on any such change, they'll get a -1.
Which options? QT_NO_FOREACH etc? Well, that one is quite important I'd wager. On the whole they have the flaw that there are too many and you need to add them in too many places, but we might make an effort to fix that. See above.
best regards, Ulf -- Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
