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

Matthew Woehlke mwoehlke.floss at gmail.com
Mon Dec 7 16:22:01 CET 2015

On 2015-12-07 07:48, Ziller Eike wrote:
> On Dec 4, 2015, at 8:01 PM, Olivier Goffart wrote:
>> Because the type is redundent 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)
> The compiler will then still not complain if you pass that ‘auto’
> variable to a function taking ‘int’ (or QString, if you don’t have
> NO_CAST_...), will it?

...it won't complain any *less* than if you'd done the cast in an
assignment. But it *might* complain, e.g. if you use the auto in an
initializer list that results in narrowing. Or it might call an
appropriate function overload for the larger type.

At worst, is equally dangerous. But in some cases it will be less dangerous.

Another argument is that the correct way to use 'int' is:

  auto i = int{list.size()};

...which will fail to compile if a narrowing conversion occurs. (Or if
you're *truly* paranoid, use 'auto' and then static_assert the actual
resulting type.)


More information about the Development mailing list