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

[Olivier Goffart]

On Friday 4. December 2015 21:35:16 André Pönitz wrote:
> On Fri, Dec 04, 2015 at 08:01:59PM +0100, Olivier Goffart wrote:
> > > > You don't see any type.
> > > > 
> > > > This code that use auto is not less readable. Even if you don't know
> > > > what's the type of bar without looking it up.
> > > > 
> > > >   auto *bar = foo->bar();
> > > >   bar->setFaz(m_factory->createFaz(bar->type()));
> > > 
> > > Isn't this kind of a bad example, because there was no type
> > > declared/visible in the first place?
> > 
> > Precisely my point!
> > There is no type visible before and nobody complains.  So why should one
> > suddenly complains there are no types in the second snippet
> 
> Because they are different from a human reader's point of view.
> 
> In the second snippet the scope of the 'bar' is larger than for an immediate
> use.

That's a good argument for the need of sensible variable name,  but not for 
mandating to write explicitly the type.

> This loses the context in which it is used, i.e. makes it harder to
> reason about whether the use is ok, and adds load on a human reader that
> needs to keep mental track of this 'untyped' item when reading the code
> until it goes out of scope in case there's another use of this item.

If you were able to reason about   foo->bar()  in the first snippet without 
having the type explicitly written, why would the human reader need to see the 
type explicitly written in the second siuppet?

> Both alternatives help to reduce that load:
> 
> - immediate consumption of the temporary makes it explicit that the item is
>   used exactly once and provides the consumer as additional context, helping
> judging whether the use is ok,
> 
> - using a separate line with a real type provides a stepping stone by
>   giving additional information about the intermediate item *to the
>   human reader*, helping him to split the task of verifying that
>   'the right thing is produced and consumed' into smaller subtasks.

There might be cases where the type name is an important information and in 
that case we should put it of course.  But in many case it is not.
In the given example, 'bar' is only used locally.
What might be more interesting is a decent variable name. 
Yet, it is frequent to see non-descriptive names for such localy used 
variable. That's because this information is obvious and redundant.

> > > I really dislike hiding types behind a generic keyword.
> > 
> > Because the type is redundent
> 
> It might be redundant for the compiler, but it is not for human
> readers of the code.


Another example:

   fazCount++; // Increment the fazCount by one.
   name.remove(' '); // Remove all the spaces from the name.

Following your argument, the comments makes the code more readable? The human 
reader might not know what remove() does? Then such comments should be 
mandatory? In practice, someone familiar with the code base will know what 
Foo::bar() returns.

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

The point is: it is just another oportunity to make mistakes.

> > It is also refactoring-proof.  Because you might want to change the name
> > of the type from "FazManager" to "FazHolder", and then you need to touch
> > less code in your refactoring
> 
> Code is typically read more often than changed. Targeting at making
> specific refactorings easier is optimizing the wrong utility function.

I'm claiming that auto often does not harm readability.
Given that, optimizing to make refactoring easier will allow the code base to 
evolve and to stay readable when things are changing



Just to be clear. I'm not advocating to use auto everywhere. I'm just saying 
that the coding style is currently too strict by forbiding auto in most cases.