> On Jun 2, 2015, at 1:59 PM, L. David Baron <dba...@dbaron.org> wrote: > > Remember that if 'auto' is forbidden, people might get around it by > not using a variable at all (and instead repeating the expression) > rather than by writing the type explicitly on the variable... and > this doesn't provide type information.
This is a point that’s worth calling out explicitly. When you write this: Foo(Bar()); You do not have to explicitly specify the return type of Bar(), and if you change both the return type of Bar() and the type of Foo()’s first parameter, you don’t have to update this callsite. If you write this: Baz val = Bar(); Foo(val); Now you’ve been forced to explicitly write out the return type of Bar(), and if you change the type of Foo() and Bar(), you have to update this call site as well. If you write this: auto val = Bar(); Foo(val); Then you’ve been able to pull the Bar() call into a separate statement without adding any additional coupling - you can change the type of Foo() and Bar() without updating this callsite, just as in the first case. An additional advantage of auto is that |val|’s type is actually the type that Bar() returns (modulo references and the like), which is _not_ guaranteed when you write out |val|’s type explicitly. If Bar()’s return type changes, but the new type has an implicit conversion to Baz, you may end up performing an conversion which you didn’t intend, and the compiler won’t catch it. This won’t happen with auto. I think there is definite value in auto’s reduced coupling and increased robustness to type changes in some cases. It can result in smaller patches which are easier to write, easier to review, bitrot less easily, and are easier to uplift, because fewer callsites need to be modified. Perhaps this will have no bearing on the final rules we adopt - I think generally the policy that auto should be used only when the code remains readable is something we can all agree on - but I wanted to explicitly call out some advantages of auto that I think are worth keeping in mind when deciding policy. - Seth _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
