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

[Thiago Macieira]

On Thursday 03 December 2015 19:49:46 Marc Mutz wrote:
> The remainder of the C++ world is moving towards an "always auto" scheme. We
> don't need to go there, but I'd at least like to propose, for new code and
> as a drive-by, the *required* use of auto for:

The remainder of the C++ world is no indication for us.

Also remember that, for us, the source code is a product. We need to have 
readable source code, so we have two ground rules that must be respected:

 1) the use of auto must make the code more readable, not less
 2) Qt Creator must be able to parse and deduce the correct type

#2 is, of course, a transient issue, because Creator will get better over 
time.

As for #1, it's subjective. "More readable" does not mean "fewer characters". 
If someone reading the code cannot understand what that variable is doing, 
then it's less readable. Thankfully, Qt API is well designed so you can 
usually tell from the function name what it does, without having to know the 
class it is defined in. But it follows that if you're interfacing with non-Qt 
API, then their API may be worse and this less readable. For example, the "is" 
prefix for boolean properties helps a lot, since you won't have to decide 
whether a plain word in English is a state or a an action, as in "empty".

> - template code (esp., but not necessarily only, when the type name would
>   require the use of 'typename')

Agreed, except when in violation of the ground rules.

> - all loop variables (both index and iterators)

Except for primitives, because "int" is shorter than "auto".

>   the reason being that spelling out the name is usually wrong:
>   size_t i = stdVector.size() // wrong, should be std::vector::size_type...
>   also helps when porting from Qt containers to STL ones

I disagree. We'll use int, thank you. You know I disagree about porting from 
Qt containers to Standard Library ones. Therefore, that is not an argument to 
convince me to write uglier code with auto.

> - all references to elements in a collection (same problem - way too easy to
> misspell std::pair<int, int> for std::pair<const int, int>...)

Example?

> Optional use of auto: whereever it makes sense. Use your own judgement, but
> remember: fear is a bad advisor.
> 
> For range-for, I'd suggest the following patterns:
> 
> - loop variable: singular name of collection name (foo : foos)
>   - otherwise: 'e' (for element) or first letter (r : rects)
> - for (auto e : collection) // (for pass-by-value types, or if you modify)
> - for (const auto &e : collection) // for pass-by-reference types
> - for (auto &e : collection) // mutating (also: pointer variables/no auto
> *&e) 

Agreed.

> - for (const auto *e : collection) // const pointers
> - for (auto *e : collection) // non-const pointer

Why? Why not allow "auto e" and e is a pointer?

> - explicit type name should be the exception

Agreed.

> This is covering a large part of the usefulness of auto.
> 
> I don't really like to add anything more detailed to the "rules". Scott
> Meyers' books do a much better job at explaining than we ever could.

Qt has never and will never build without warnings from -Weffc++. Some of 
Scott's rules are good, but we do not have to adopt them all.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center