[Development] QtCS2019 Notes: QtCore

André Pönitz apoenitz at t-online.de
Sat Nov 23 09:47:23 CET 2019

On Fri, Nov 22, 2019 at 08:01:30PM +0100, Giuseppe D'Angelo via Development wrote:
> Il 22/11/19 18:49, Thiago Macieira ha scritto:
> > We decided not to add q6sizetype. Just add a "### Qt6: qsizetype" comment
> > where you can't use qsizetype in Qt 6. We'll deal with conflicts.
> Sorry, what do you mean by "conflicts"? I mean that there's countless code
> today that uses "int s = foo.size()" (or indexOf, or similar); such code
> will now trigger narrowing warnings.
> > There's always QVector<T>::size_type, QByteArray::size_type and
> > QString::size_type if you really need to be explicit and that's fine today.
> The chance that non-generic code uses this is practically 0 and we know it.
> Yes, "auto" will work, but still has anyone actually did the exercise on a
> big codebase (Creator, KDE, ...) and checked how many warnings are we
> talking about?

My current assumption is that it will be an unrealistic effort to actually
fix the cause for the warning, so not enabling narrowing warnings flags is
the most likely cause of action at least for Qt Creator.

Now that you spell out the problem, it occurs to me that we might
even have the cake and eat it in this case:

Most (all?) containers have currently several functions to return their
size, e.g. QVector::{size,count,length}. We could one of them continue
to return an int.

So adapting a codebase would be just replacing the now qsizetype-returning
variant by an int-returning variant, which is rather easy and safe, compared
to fiddling with actual type changes.

So let's make this a real proposal: Should we have

   qsizetype QContainer::size()
   int QContainer::count() const



More information about the Development mailing list