[Development] qsizetype

[Hasselmann Mathias]

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 <apoenitz at 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 at qt-project.org
> https://lists.qt-project.org/listinfo/development