[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.

[clappski]

I'm currently working on a code base that's just upgrading to MSVC 10.0, and seeing std::vector::value_type(?)::const_iterator everywhere is killing me.

[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.