Just to elaborate on what danking00 is saying, the extra syntax in this case is not adding any extra information (to the compiler). The left hand type of the expression can be completely inferred at compile time, in this case. What that required syntax is adding is pain, but no gain (except for imperceptibly faster compile time).

In Haskell this would look like:

  TagDataMap = [
          ("title", ((3, 30, stripnulls)),
          ("artist", ((33, 30, stripnulls)),
          ...

Haskell will correctly infer that TagDataMap :: [(String, (Integer, Integer, String -> String)].

Ok, technically this is an associative list, not a Python dictionary, but it is a map and can be accessed like one. Hell, most people use dictionaries with less than 10 items, which are much slower than arrays most of the time

Even in Hindley-Miller type systems it is considered good practice to add types as documentation to top-level constructs (see Haskell). In Python it is also considered good practice to add argument and return type info in the doc string. In a dynamic language you would also have to add a unit test or two for cases for some of the things that the compiler can catch for you.

Looking at the complete picture makes a language with local type inference (like C++11) more or less as verbose as one with complete type inference.

Wrong foundation? No. Foundation you don't want? Sure.

Try to remember that Hindley-Milner is very hard to do outside of functional languages like ML and Haskell.

One thing you cannot do is infer `const`ness. This isn't a problem in Hindley-Milner systems because variables are not assignable--they're all `const`, all the time. Literals are inherently immutable but when you assign a C++ variable a literal value, sometimes you want a const variable and sometimes you don't.

I don't think C++ can figure out the map<..> part simply because lots of things could have list initializers that accept lists of 2 item lists. C++'s overloading and implicit conversion conflicts with perfect type inferencing. This is an example of the kind of thing the FQA talks about, where several of C++'s issues collide to produce counter-intuitive behavior.

I do wonder if you could get away with this:

    const map<const auto, const auto> TagDataMap { ...

I don't have access to a C++11 compiler from where I am to find out though. I am particularly unclear on the interaction between `auto` and other aspects of a type declaration--I don't know if you can nest `auto` like this deep inside some other type declaration. I don't see why you couldn't, but wouldn't be shocked either.

But aren't all allocation styles basically the same once you get GC? (I guess unless you broaden the scope of the word, and let it describe the lengths you go in Haskell to avoid allocation at all, aka triggering stream fusion and automatic deforrestation in general.)

I am picturing Python drowning in isinstance checks to avoid constant crashing every time a new function is added.