Andrei Alexandrescu:
I'm torn on this. The arguments make sense; on the other hand,
people will in all likelihood write their own code in the style
promoted by the doc examples.
How about this - use auto for code samples, but not for
documenting function return types (except Voldemort)?
Generally I'd like the documentation examples to not use auto,
because this makes the examples more clear and less easy to
misunderstand.
Programmers are lazy, so I think D programmers learn quickly how
much handy 'auto' is. So I think the risk you refer to of them
not using auto in their code is low.
Teachers know that usually you have to teach people the less
handy things, because students learn the lazy things more
quickly. Example: in D.learn someone was saying that adding the
immutable/const/pure/nothrow annotations is boring.
In my code I use often auto for variable defined inside
functions, but usually I write the real return type of functions,
because this helps me understand better the code I am working
one, it's more self-documenting. Even in Haskell, where there is
a powerful global type inferencer, you usually write down the
types of inputs and outputs of functions, for similar reasons.
Bye,
bearophile
