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. 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. 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. > > 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. > 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.] > 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. Andre' _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
