> On 5 Sep 2022, at 19:15, Marc Mutz <marc.m...@qt.io> wrote: > > 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).
Hey, It’s great that we have the tools to make most of the changes gradually, thank to you, Ivan and others. And I agree that we should keep going, in those modules where the relation between the problem we are solving, and the effort it takes, is sensible. Thanks for taking the lead on that. But for many modules, there is simply no use case for >2G data, and whatever theoretical issues people might be able to provoke by passing huge lists or indices into APIs are constructed and self-inflicted. For instance, I don’t see why we need to prepare QGraphicsScene or QAbstractAnimation’s implementation to handle >2G items, in any of the lists they are operating on. Is every narrowing when converting to fixed points a serious problem? I don’t see that. And a lot of people working on keeping Qt’s UI and rendering functionality competitive will not want to spend time reviewing and arguing about changes that bring 64bit safety to code that has absolutely no use for that (e.g. we don’t need >2GB opengl buffers). At least you need to make sure that the maintainers of those modules are onboard, are willing to join, or at least review your patches. For those modules, doing things gradually as drive-by’s when we touch the respective code anyway, will be fine (at least as far as trivial s/int/qsizetype, or refactoring to ranged-for is concerned). > 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. I agree that it would be great if users of Qt could flip on aggressive compile options to get warnings about narrowing-conversions. But again, is that worth it? And is that more important to users than having a few releases of Qt where they don’t have to constantly chase after new deprecations? I honestly doubt it. I know a few folks in the Creator and Design Studio teams that would love a Qt release or two with no new warnings. So, I in principle agree with your plan, but let’s focus on the modules where there is at least a plausible usecase for >2G data. For the rest, reach out to the respective maintainers, please. Volker _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
