My take on qsizetype: Just revert this failed experiment. It's a huge
annoyance for little to no benefit. I'll never understand how this very
broken and incomplete experiment could make it into Qt's main branch at all.
Am 13.09.2022 um 15:12 schrieb Volker Hilsheimer:
On 12 Sep 2022, at 20:04, A. Pönitz <apoen...@t-online.de> wrote:
On Wed, Sep 07, 2022 at 06:38:30PM +0200, A. Pönitz wrote:
On Mon, Sep 05, 2022 at 05:15:45PM +0000, Marc Mutz wrote:
[...]
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
[...]
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,
I currently fail to understand why all this work needs to have user-visible
consequences *at all* before 7.0 - especially, but not limited, to the now
apparently planned incoming stream of source-incompatible changes including
related deprecations starting to hard-hit users from 6.8 on.
What would have been wrong with starting with
#ifdef I_AM_WORKING_ON_IT
using qsizetyp_ = qsizetype;
#else
using qsizetyp_ = int;
#endif
then have the people working on it (and only those, plus perhaps potential
early adopters) define the macro locally, "port" int to qsizetyp_, and when
everyone is happy with the scope and the implication ofthe change, at 7.0 time,
globally replace qsizetyp_ by qsizetype ?
Why is all this done as operation at an "open heart" instead of having
a "staging" and "production" setup?
Could anyone involved in the decision making that resulted in
the approach taken here please comment?
I can't claim that I was involved in the decision making, but here’s how I see
it:
We have the tools to change - with some limitations - API signatures without
breaking either source or binary compatibility. We can deprecate and “weaken”
old overloads in favour of new overloads; or we can remove the old overload
completely from the public API and still continue to export the old symbol
through the module-specific ‘removed_api.cpp’ files.
This is conceptually great news, it gives us a bigger toolbox than what we had
before. Technically, this is very powerful and useful, allowing us to fix
mistakes gradually, while giving users control over what kind of deprecation
warning level they want (from completely silent, up to code no longer
compiling).
This is IMHO superior to a temporary type alias: A string-based signal/slot
connection where the signal has been ported ot emit a qsizetyp_ while the slot
still receives int will fail. So that would break source compatibility. But if
both slot overloads are still visible for moc when Qt is built, but not to the
compiler when Qt is used, then those connections will continue to work.
So, I think we have the right tools. The discussion we need to have is when to
use them. As I have proposed in this thread: this has to be a case by case
decision.
QTimer should allow timeouts longer than 2^31 msecs, i.e. < 25 days. Great that
we could fix this before Qt 7.
QDir::count and operator[] now work with qsizetype. I suppose there can be >2^31 files in
a directory, perhaps more so in 10 years than now. Nevertheless, I do wonder whether this is
worth the potential source compatibility breakage that is pointed out in the comment
message. But as long as users need to opt into deprecation warnings explicitly, that is ok
as well (and would be a “staging" and “production" setup, in practice).
Volker
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
