[Development] RFC: more liberal 'auto' rules?

Matthew Woehlke mwoehlke.floss at gmail.com
Fri Dec 4 22:33:26 CET 2015

On 2015-12-04 15:35, André Pönitz wrote:
> On Fri, Dec 04, 2015 at 08:01:59PM +0100, Olivier Goffart wrote:
>> and it's one reason less to make errors:
>> Using 'int' instead of 'quint64' or 'size_t', or QString instead of QByteArray 
>> is way to frequent. (and the compiler won't complain)
> ["QString instead of QByteArray" does not happen with proper
> QT_NO__CAST_*_ASCII settings.  Not to mention the cases where mindless
> replacement of explicit types by 'auto' doesn't produce identical results.]

But wrongly mixing integer types *does* happen. I speak from personal
experience based on a code base that has a relatively large mess of
*exactly* such errors.

> Code is typically read more often than changed. Targeting at making
> specific refactorings easier is optimizing the wrong utility function.

Which of these is easier to read? (More importantly, which is easier to
*verify* that it is correct?)

  for (int i = 0; i < list.size(); ++i)

  for (auto i : qtIndexRange(list.size())

Which is *really* more meaningful? "The type of 'i' is 'int', and I
really, really hope that 'list' is actually indexed by 'int'", or "the
type of 'i' is the index type of 'list'¹"?

Do you really *care* what is the type of 'i'? Or do you care that it is
the *correct* type. I (and others) submit that the latter is more valuable.

(¹ ...assuming that decltype(list.size()) is the index type, which it
had darned well better be or whoever wrote the API of decltype(list)
needs to have their coding privileges revoked.)


More information about the Development mailing list