[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)
    foo(list[i]);

  for (auto i : qtIndexRange(list.size())
    foo(list[i]);

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.)

-- 
Matthew




More information about the Development mailing list