[Development] QtCS2019 Notes: QtCore

[André Pönitz]

On Sun, Nov 24, 2019 at 09:48:46PM -0800, Thiago Macieira wrote:
> On Sunday, 24 November 2019 00:50:14 PST André Pönitz wrote:
> > Regarding the risk of "introduce subtle bugs by truncating sizes": That risk
> > _is_ there in general for some of the proposed porting strategies, but not
> > for the case of using a 32bit count(): We can assume that an existing
> > application using QContainers is fine with 32bit, otherwise it wouldn't
> > work right now. So continuing using 32bit interfaces does not introduce
> > bugs. Immediate truncation on the user code sode is also riskless, just
> > ugly.
> 
> I'm not talking about porting code.

> I'm talking about new code written in 2024. If we choose now to have 32-bit 
> count(), that will still be the case in 2024, possibly beyond, which means as 
> a result code written at that time needs to be careful not to use the 32-bit 
> methods.
>
> That's what I am referring to when I say a problem down the road.

And I am concerned about porting code, because that's what keeps me busy
nowadays.

2024 is four years ahead. That's quite some time in Qt's life. 2011's burning
platforms looked different in 2015, and 2015's paradigms (OpenG?L, JS?)
do not apply in 2019 anymore.

It's ok to keep in mind that there will be 2024 at some time, but it's nothing
worth sacrificing current usability for.

Unless the rest of Qt interface is adapted to use qsizetype, including places
where it's obvious overkill like, say, QComboBox::maxVisibleItems, user code
will from 6.0 always have to decide on what integer type to use. 

This is trivial for each instance, but since _a lot_ of code is affected,
this will sum up to a significant effort when writing and reading Qt code.

Andre'