[Development] qsizetype

A. Pönitz apoenitz at t-online.de
Wed Sep 7 18:38:30 CEST 2022


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?

Andre'


More information about the Development mailing list