[Development] qsizetype

A. Pönitz apoenitz at t-online.de
Mon Sep 12 20:04:44 CEST 2022


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?

Andre'


More information about the Development mailing list