If you need iterator, you probably have container, e.g.
Such container is probably used in several places and may be typedef-ed.
ObjectArray::Iterator is much less scary, isn't it?
But it is an issue what is more readable: long name with all related types or typedef abbreviation.
This is not a problem of
auto itself. It's mostly about 'interface-oriented' programming style when you work with public interfaces (e.g. public methods or properties) instead of concrete types. C++ templates are usually written in such style, and this style is common for script languages like Lua or Pyhton.
And I agree that 'interface-oriented' code is harder to understand than classic 'object-oriented'.
Urho has a bucket of rules like 'no tabs', 'use camel case' etc. They are strict and easy to follow.
The probem with
auto is that anybody have his own criteria where to use
auto and where not to use.
If @cadaver just say 'follow the common sence', Urho may end up in codestyle mess because everybody has its own (of course, evident) rules.
Just look at these examples and try to answer where to use
auto and where not to (and why):
Vector<HashMap<String, Pair<Node, Component>>>::Iterator
very long and ugly iterator
just quite long iterator
this type is not an iterator, but still long
as long as 2) but almost the same as 3)
as long as 2) but the same as 3)
pretty short iterator
as long as 6) but not an iterator
const HashMap<String, int>&
longer than 6) but not an iterator