Auto Type Deduction in C++ Range-Based For Loops

[creed]

I don't like that at all.

Sure if you consider:

for (auto& p : wordCount) {

    // ... word: p.first, count: p.second

}

then

for (auto& [word, count] : wordCount) { // C++1z

    // ...

}

seems like an improvement because you immediately know the semantics of the two parts of the pair. But you have no idea what "word" or "count" is. In this example with words like "word" or "count" the semantics somehow encode type information but most of the time you deal with user defined types where that information is a) not clear and b) not as trivial.

To me this whole "auto" thing seems misunderstood. People use it to make their lifes "easier" (think lazy) but not simpler. The type system is there to help you and type information is of uttermost importance and should be available as closest to the usage as possible without destroying readability so you don't have to look it up somewhere else.

using wcPair = std::pair<const std::string, int>;

for (wcPair& p : wcMap) {

  std::cout << p.first << " : " << p.second << std::endl;

}

seems reasonable enough. The loop itself can be read without clutter, you can infer what's supposed to happen without knowing much stuff and even if you want a deeper understanding of what's going on then the information you need is right above.

Doesn't that seem much better? oO

...and if you want a language without a type system don't use a language with a type system.

[jasode]

>...and if you want a language without a type system don't use a language with a type system.

I wasn't the one who downvoted you but I'm guessing it happened because your advice is misguided and it shows how you're confusing the ceremony of a human bashing extra keystrokes to repeat annotations everywhere with the concept of static typing that enables compiler correctness checking. The keyword "auto" enables the separation of those 2 concepts. Type inferencing and type deduction is the technology that gives you "types" without the tedious "ceremony".

[maxlybbert]

  > if you consider:
  >
  > for (auto& p : wordCount) {
  > ...
  > But you have no idea what "word" or "count" *is*.

If you know what wordCount is, you'll know what types word and count are.

I remember back when I was still a very new programmer I somehow got the syntax for an iterator-based loop wrong ("for std::vector<int>::iterator itor = v.begin(); itor != v.end(); ++itor)"). I don't remember my mistake. I probably missed a const somewhere. The compiler told me that "std::vector<int>::iterator" did not match the type of v.begin(), but it wouldn't tell me what would match. Even as a beginning programmer, I knew the compiler knew, but all it would say was "you got it wrong."

And, of course, I didn't care what the type of v.begin() was. All I cared about was whether I could iterate over the elements of v. And I knew that v contained int's.

Many programmers learned about strong typing ( https://en.wikipedia.org/wiki/Strong_and_weak_typing ) and static typing ( https://en.wikipedia.org/wiki/Type_system#STATIC ) in languages that require manifest typing ( https://en.wikipedia.org/wiki/Manifest_typing ), so they often don't realize those are three distinct ideas. You can write strongly typed programs in Haskell, Ocaml, Go and Rust without many type statements.

[michaelfeathers]

The experience of other language communities is: you'll get used to it. When C# introduced its version of this with the 'var' keyword many felt that code would become less clear but, in general, context gives you what you need. If it doesn't that often means that there are other problems.

I don't know if this is true in your case, but often people who object haven't spent much time working in dynamically typed languages. The readability issue is orthogonal to typing and it tends to be fine.

[jschwartzi]

The purpose of the type system in C++ is partly to encode semantics about the usage of a particular construct. For example, we might declare three or four types which all support the increment() function(or operator). The traditional way to do this is to create an interface and have the four concrete types inherit from the interface.

What auto says is "I don't care what type this value is. I just want it to support the semantics that I'm about to describe in this block." If you change the return type of the value in the auto expression, as long as the new return type supports the same semantics as the original return type, you don't need to touch that function after the refactor.

The compiler still complains when it can't find a way to make the return value support the semantics you're asking for. This is an improvement, but only in cases where you genuinely don't care what type it is, but only that it supports iteration. You still have to use auto with care, like every other keyword, but it does significantly improve maintainability in code bases where traditionally you would mechanically key in the same type information multiple times throughout the declaration of a class and its usage. Typedef and using statements solve similar problems, but they don't solve exactly the same problem.

For a good example of why this is a wonderful thing, try to determine what return type you should declare for an STL iterator, or try using Boost while avoiding the auto keyword.

[overgard]

With regard to your example, in any decent IDE you can mouse over "auto" and get the type information. However p.first and p.second are obscure and hard to read no matter what your tools do.

I don't get why people seem to think type inference equates to a hatred of static typing. Usually if I'm reading code I want as little clutter as possible, and if I need to know the type it's trivial to find it. I still like that I can know the type of something ahead of time, but I don't need it in my face constantly.

[catnaroek]

Static typing doesn't always require type annotations. Type inference is 1970's era technology.

[dmoy]

There's definitely a way to abuse it. But if, for instance the type is shown a couple lines up, it's not too bad. E.g. if the for loop is iterating over a var passed into a function.

[randomguy1254]

I use const auto on occasion, when the element type is inexpensive to copy. If I'm iterating over a vector if int's, why would I prefer const auto& over const auto? Assuming the compiler does not try to optimize the const auto&, const auto should be faster than accessing a value through a reference.

[s3rvac]

Using const auto& over const auto makes your code more robust. For example, what if you later decide to change the type of items in the vector from ints to something that is more expensive to copy? You would need to track all uses of the vector and add an ampersand there. And as for the access speed, YMMV but compilers are generally good at optimizations and will drop the reference when it would be faster to just copy the items.

[captainmuon]

Huh, I always thought that there is an optimization to always choose the most consty and referency option possible. So if you write `auto` but don't modify the item in the loop, it may choose to use a reference / pointer under the hood, as if you wrote `auto &` or `const auto &`. But it can't strip away the `&`.

The reason is that I imagined C++ can substitute anything for auto, so it can make `auto` into a pointer to Foo, but it can't turn `auto &` into `Foo`. (In a first pass, of course due to the as-if rule the compiler can do whatever it wants when you are not looking.)

In the example the author reccommends against, `for (const auto x : range)`, I would think it means:

- const: don't let me modify x (enforce const-correctness at compile time)

- Make a copy or reference, whatever is faster.

Particularly, I think/thought: `const` does not tell the compiler to make a copy. The lack of `&` allows the compiler to make a copy.

I'm sure this interpretation is not 100% what's in the standard, but a intuition I developed from observation, so probably some of it is wrong.

[revelation]

auto doesn't mean "make a copy or reference, whatever is faster". auto first and foremost means "make a copy". Then sometimes compilers can do a trick called copy-elision and you might be working on a reference. But generally assume it's going to be a copy.

auto& means only make a reference.

[jmaschad]

Wouldn't one want to use 'f(std::forward(x))' with 'auto&&' ?

[lorenzhs]

I think the example with function application is a bad one here - moving the element potentially leaves it in an undefined state. It would be a better example if the code did something with x instead of calling a function on it.

So I don't think you'd want to forward it. Note that you also need the element's type to forward it, which isn't possible in general with the example's signature.