With Respect to « Proper Usage » of auto

The auto keyword was traditionally reserved for what we could simplify as « a local variable » (automatic allocation, on the stack, as opposed to static) and was traditionally not used since is was essentially redundant. Since C++ 11, this keyword makes it possible to express, when defining a variable, « the variable's type is the same as the type of the expression used to initialize it » (minus références and const and volatile qualifications).

For example:

static const int glob = 3;
int &f() { return glob; }
int g() { return glob; }
int main() {
   int i0 = glob;       // i0 is int and is initialized with a copy of glob's value
   auto i1 = glob;      // i1 is int (not const) and is initialized with a copy of glob's value
   auto i2 = f();       // i2 is int (not int&!) and is initialized with a copy of glob's value
   auto i3 = 0.5 + g(); // i3 is double since expression 0.5 + g() is double
}

Quite a few experts are debating the merits of using auto to « specify » a variable's type There are at least three groups involved:

• The AAA group, for Almost Always Auto, a name we owe (as far as I know) Herb Sutter (see http://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/ among other texts) whose reputation is quite solid
• The group I'd call the AAAA group, for Almost Always Avoid Auto, a name whose parenthood I'd give to the nice and  brilliant James McNellis and his 2015 tweet https://twitter.com/JamesMcNellis/status/629710738890752001, an opinion that meets one I've heard expressed quite often by experienced programmers. Indeed, Michael Caisse, another very nice person and renowned expert, has backed James McNellis strongly in https://twitter.com/MichaelCaisse/status/630834506090549248)
• The group I'd call the CRA group, for Contextually Relevant Auto (feel free to tell me if you have a better name to suggest!), which uses auto when that's contextually relevant. That's pretty much where I personally am on this issue: I look favorably on auto but with moderation. This position needs to be precised, which I'll try to do here.

The AAA Position

The AAA position recommends that we use auto to define a variable almost as a reflex. This position states (rightfully) that the resulting text is homogeneous and prevents such things as forgetting to initialize a variable.

int i = 0;

auto i = 0;
// or
auto i = int{};
// or
auto i = int();
// or
auto i = int{0};

auto i = int();

int i();

std::vector<std::string> v = { "I love", "my", "teacher" };
for (std::vector<std::string>::const_iterator it = v.cbegin(); it != v.cend(); ++it){
   std::cout << *it << ' ';
}
// or
for (const std::string &s : v) {
   std::cout << s << ' ';
}

std::vector<std::string> v = { "I love", "my", "teacher" };
for (auto &it = v.cbegin(); it != v.cend(); ++it){
   std::cout << *it << ' ';
}
// or
for (const auto &s : v) {
   std::cout << s << ' ';
}

tetemplate <class It>
   void f(It begin, It end) {
      typename std::iterator_traits<It>::difference_type dist = std::distance(begin, end);
      // ...
   }

template <class It>
   void f(It begin, It end) {
      auto dist = std::distance(begin, end);
      // ...
   }

template <class M, class F, class ... Args>
   auto minuter(M minu, F f, Args && ... args) -> std::pair<decltype(f(std::forward<Args>(args)...)), typename M::duration> {
      typename M::time_point before = minu.now();
      decltype(f(std::forward<Args>(args)...)) result = f(std::forward<Args>(args)...);
      typename M::time_point after = minu.now();
      return std::make_pair(resultat, after - before); 
   };

template <class M, class F, class ... Args>
   auto minuter(M minu, F f, Args && ... args) {
      auto before = minu.now();
      decltype(auto) result = f(std::forward<Args>(args)...);
      auto after = minu.now();
      return std::make_pair(resultat, after - before); 
   };

Using auto to define a variable turns uninitialized variables into illegal expressions. Indeed, this would not compile:

auto x;

... whereas this would compile but leave x in an uninitialized state:

int x; // legal, but...

Aesthetically speaking, an upside of using auto is that it aligns variable names as they are being defined in a given block, all « type names » being of the same length.

The AAAA Position

The AAAA position is that using auto when defining a variable distances source code from its semantics, which can lead to errors and complicate maintenance.

auto s = "I love my teacher";

auto s = string{"I love my teacher"};

auto s = "I love my teacher"s;

auto x = d + sizeof(T);

std::vector<std::string> v = { "I love", "my", "teacher" };
for (auto s : v) {
   std::cout << s << ' ';
}

template <class M, class F, class ... Args>
   auto minuter(M minu, F f, Args && ... args) {
      auto avant = minu.now();
      auto result = f(std::forward<Args>(args)...);
      auto apres = minu.now();
      return std::make_pair(resultat, apres - avant); 
   };

Clearly, using auto should not lead us to stop thinking when we are coding.

The CRA Position

Essentially, why do we use auto when we do so?

On the teaching front, the virtues of auto are many: simpler indentation when defining variables, simple directives that work well in general for beginners, reduced risk of uninitialized variables, etc.

In practice, auto is not magical, and using it without thinking can lead to unpleasant side-effets, in particular when manipulating integers (issues of size and signedness). Of course, coding without thinking is a questionable practice, with or without auto.

Using auto is a good idea, in my mind, when:

• The actual type is clear from the immediate context, but would be painful to express explicitly, or
• The exact type is not important, as long as it meets the local algorithmic constraints

In a situation such as the following:

template <class It>
     void f(It begin, It end) {
        auto dist = std::distance(begin, end);
        // ...
     }

... I'm not convinced that writing auto instead of typename std::iterator_traits<It>::difference_type has a detrimental impact on readability or on readability. Indeed, I think that:

• What interests programmers in this case is that dist represents the number of elements in the sequence
• If a programmer is not aware that dist is a signed integral type in this case, I doubt explicitly expressing its type will add this awareness
• Algorithmically speaking, if function f() needs the type of dist elsewhere, for example in order to declare another variable of the same type, then decltype(dist) will probably be the best option in this situation

Likewise, take this function:

template <class C>
   void afficher_elements(const C &c, std::ostream &os) {
      for (auto &val : c)
         os << val << ' ';
   }

In this case, supposing that c is a container, it's possible to express the exact type of each element explicitly:

template <class C>
   void afficher_elements(const C &c, std::ostream &os) {
      for (typename C::const_iterator it = c.begin(); it != c.end(); ++it)
         os << *it << ' ';
   }

That being said, what would we gain from this explicit typing? Is it clearer? Easier to maintain?

Then, of course, abusive usage of auto does exist. The poster child probably is:

auto n = 0;

... where using auto takes more characters than using int explicitly, and runs the risk of confounding those who will read the code a posteriori. Likewise, this:

template <class T, class F>
   void g(T val, F f) {
      auto x = f(val);
      // ... lots of code
   }

... can be tricky. What's the intent behind the application of f to val? What does g() expect of x in practice? Here, constraining the type of x would at the same time be a form of in-code documentation and a guide to its ulterior maintenance.

My Personal Usage of auto

I personally write auto when:

• The type is clear from the context in which it is used, and does not seem to induce confusion
• There's an actual gain in writing; for example, it oftens seems like a win for me to replace with auto a type that's very long to express, or that depends on a function's arguments without really varying semantically with respect to the algorithm

I avoid auto when:

• Not explicitly stating the type appears to me as obscuring the purpose of the algorithm or complicating code maintenance
• I am of the opinion that the code would benefit from explictly stating the constraints its type expresses

Whenever it's reasonable to express type constraints, we have many options (not necessarily in order of preference, such an order being somewhat cultural):

• Functions with enable_if
• Static assertions
• Interfaces
• Concepts (used as Constrained Auto)

What about the AAA approach, which recommends almost always using auto? In some projects, maybe, and it seems reasonable for teaching some introductory programming classes.

What about the AAAA approach, which recommends avoiding auto except in select cases? I would not go as far, the cases of meaningful auto seem too numerous to me to impose such a restriction.

Is the type clear from context? Then, auto is probably appropriate.

Is the exact type irrelevant in the context of the algorithm? Then, auto is probably appropriate.

Some Thoughts...

A direct consequence of auto usage is, it seems to me, a greater emphasis on explicitly type literals, inclusing user-defined literals. I'm not sure what to think of this yet, but it is a twist given existing practice, where we had a tendency to let constructors perform conversions for us given literals of various types. This was something one could observe already through usage of such functions as std::accumulate(), as the return type of that function is determined by the type of one of its arguments.

Acceptance of auto is in large part driven by our habits in generic programming. We have come to accept using very abstract types in our code, which are only determined at point of usage, typically far from the location where the templates are actually expressed. The tools we have built (traits in particular) to constrain types and precise our intentions remain valid, but are sometimes a burden. I do not think auto replaces them completely, even though it plays a rule in alleviating some of their tediousness.

I expect concepts, as they become available, to replace auto usage in some cases. They are not as tedious to write as things such as traits on dependent types, and constrain generic code just enough to make the intent clear and code more robust.

In a 2015 presentation on migrating code from C++ 03 to C++ 14, Joel Falcou examines auto from a compile-time-shortening perspective, and offers the following guidelines :

• Follow the AAA philosophy (he adds « in a viral way ») to ensure compile-time performance
• More specifically, he recommends using auto all the time, except :
  • in non-template, public API return types
  • when a concrete type is explicitly needed for external reasons

He adds that decltype should be used for metaprogramming tasks and SFINAE context in auto return types. These, in his experience, bring the best compile-time performance results, as long as one remains conscious of the caveats of auto deduction rules, discussed at length in Scott Meyers' Effective Modern C++ book.