> On 7 Sep 2022, at 08:36, Alex Blasche <alexander.blas...@qt.io> wrote: > > Hi Volker, > >> ________________________________________ >> From: Development <development-boun...@qt-project.org> on behalf of Volker >> Hilsheimer <volker.hilshei...@qt.io> > >> 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. > > I'd like to rephrase the above to ensure I correctly understand Volker here: > > The suggestion is to do the conversion to API's which benefit from >2G data > only. In such cases the changes would be done such that we only add the > converted API behind guards which come into effect in Qt 7 > (QT_DEPRECATED_SINCE/QT_REMOVED_SINCE(7,0)). This means we don't need fancy > overload solution for getter like > > int size() vs qsizetype size() > > as we are talking about a switch at Qt 7 time. Is this your suggestion > Volker?
Short version: In principle, yes. For some definition of “benefit”. I think there is a significant amount of code where we can simply live with the status quo, even if it’s not ideal. The rest still need to be evaluated case-by-case, and waiting for Qt 7 will not always work. Long version: Marc has stated that >>> 'That said, no actual user-visible size-mismatch bug has yet required the >>> change of public interfaces.’ That’s good. As per that statement, this is hopefully not going to be a major source of API deprecations or otherwise incompatible changes. But it is a major source of work. There are a few no-brainers, like QBuffer [1], or even QDataStream [2] - these are bugs, thanks for fixing the one, and please don’t wait until Qt 7 with the other. [1] https://bugreports.qt.io/browse/QTBUG-102171 [2] https://bugreports.qt.io/browse/QTBUG-105034 But then I’m looking at https://bugreports.qt.io/browse/QTBUG-104824 and even though QMdiArea doesn’t have any public API operating on int, I don’t expect anyone to spend time on changing the implementation to use qsizetype (or auto, or ranged-for). And I will understand if maintainers get somewhat upset if they are expected to review such patches. > I would support this solution as I have the same concern about never-ending > porting requirements for our users. Looking at the two cases that are quoted to have required API changes in the various JIRA tickets under the https://bugreports.qt.io/browse/QTBUG-102461 epic: QByteArrayList::join now supports separators >2G [1]. QVersionNumber, operating on a QList<int> as segments, now uses qsizetype in APIs directly related to accessing elements or slices of that list [2]. [1] https://codereview.qt-project.org/c/qt/qtbase/+/379810 [2] https://codereview.qt-project.org/c/qt/qtbase/+/389682 If either of those changes would have resulted in deprecation warnings for users, should we have made them anyway? I don’t think so. I’m sure there will be cases where we have to deprecate API in order to fix legitimate issues. For changes that result in porting efforts from our users, we should have *very* good justification: data loss or corruption, or potential security issues, etc. There are hopefully few of those, and we can hopefully take each of those case-by-case. The respective maintainer should make that call, hence my request to involve them in the discussion, and to not just throw patches at them for review. Speaking as a maintainer: Yes, there are legitimate use cases for e.g. a QSqlTableModel to operate on tables with >2G rows. And there are legitimate use cases to have a QSlider for a wider range than 4G. We cannot change those APIs without breaking compatibility. Indeed, it would be nice to have a consistent API, and to support those use cases. But even if we could make those changes without breaking ABI compatibility - as long as we are putting a porting burden on our users, I would not be on board with making them within Qt 6. For everything that doesn’t have strong justification, cannot be changed without impact on existing client code, or - as far as implementation is concerned - has no plausible usecase for dealing with >2G items, we can still gradually annotate our code and our API via `#if QT_VERSION` or `QT_DEPRECATED_SINCE(7, 0)`. Esp since we hopefully don’t have to think systematically about a Qt 7 for several more years, adding those annotations to the code seems better than peppering the code with // ‘### Qt 7’ comments that someone hopefully greps for, or creating JIRA tickets that we then have a hard time finding. And it will be rather easy to evaluate what that ultimately means for a future porting effort from Qt 6 to Qt 7. When the time comes, we can still discuss whether we accept it, and what we can do to ease the transition. Volker _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
