Hi, Experience shows that we'll have many, many, many things to consider come Qt 7. And as Qt 6 has shown, such trivialities will be left by the wayside. So, playing the devil's advocate here: if this work is too much for Qt 6.x, what makes us think we'll get it done in the frenzy leading up to Qt 7.0?
We have the tools (QT_REMOVED_SINCE + Ivan's work on -disable-deprecated-until) to have a user-configurable, rolling BC window now. We should use these tools to avoid accumulating too much technical debt until 7.0. From a C++ POV, we now only need major versions to break polymorphic inheritance (incl., but not limited to, virtuals), and signals and slots (the latter because of conflicting SC-solutions for new-style and old-style connects). That said, no actual user-visible size-mismatch bug has yet required the change of public interfaces. So there's definitely two stages here: 1) fixing the implementation (we must do this) and 2) fixing the API (much less urgent iff our headers are clean w.r.t. aggressive narrowing warnings (-Wnarrowing) so users can enable them for their own projects to catch the bugs at the API boundary). So, I think the priority and therefore work order should be: 1. Fix all int/uint in the implementation 2. Fix our headers (public and private) to be resistant to aggressive narrowing-conversion compiler warnings 3. Enable said compiler warnings for (growing subsets of) Qt implementation code 4. Fix our APIs Seeing as user-side truncation occurs when passing to function arguments, and seeing that function arguments are much less critical when it comes to SC than function return values, we might even split the API update part to fix setters first, and only then getters. That said, sometimes it's just simpler to do the API change together with the rest. I wouldn't worry too much about the effect this has on users of Qt APIs: Function argument widening is SC, and function return value widening can be buffered with liberal use of auto on the side of the user (I don't want to count the number of trivial bugs that would have been prevented in the Qt5->6 port if Qt didn't have such a conservative stance on the use of auto). We should just communicate clearly that for the next few releases, any int in the API is subject to potential porting to qsizetype, and suggest users to prepare their own code for the change, ideally already in the Qt 6.4.0 changelog, and then in all following ones. Thanks, Marc
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
