> This should have been in C++ from its inception to be honest

It was, but the backslash was even greater back then, so Bjarne removed it from C with Classes.

There are a few presentations/interviews where he mentions it.

That was an entirely different auto. In C89, auto just "variable on the stack". It still had a type. The new auto is just borrowing the keyword since it (a) makes sense and (b) is already a reserved word.

How the keyword was named when Bjarne introduced it doesn't matter, the purpose was the same as C++11 auto.

It was entirely another concept.

Before C++11 auto meant it was not static, extern or register, and in fact every single variable was already implicitly auto if no specifier from the previous list was applied.

    int n = 10;

In that line, n was auto. Now it is not auto, only int.

Type inference is orthogonal to whatever keyword is used.

Bjarne used another keyword in C with Classes, removed it due to backslash, and the commite decided to re-purpose auto for the same purpose in C++11.

No big deal, the meaning of static is also context dependent, and no one is fighting against it like it happens with the new meaning for auto.

> This should have been in C++ from its inception to be honest, to avoid blah_type<with_this> something = new blah_type<with_this>() repetition.

Type inference for this is about the only way to make "enterprisey" C#/Java code palatable.

The only problem is if you're a .NET shop that is a little crusty, and people start having PTSD flashbacks and conflate the C# type inferred "var" with the old VisualBasic monstrosity Variant type.

Personally, I wee it more like the bad old days before "Option explicit" and "Option strict" being turned on and every variable being declared as "dim x" with no type. Sure, that then used a variant in the background, but the chaos it installed is what scares the crap out of some shops with regards to "var" and C#. If you were a good VB.Net citizen, you always newed up your variables like : "dim x as new Y()".

Agree, Golang has := by default

I don't know Go. What does := do?

x := some_code_here says "x is a NEW variable whose type is whatever the result of the expression on the right hand side is".

Say we have a function, GetInt64(), which...returns an int64. x := GetInt64() both declares x to be an int64 and places the resulting value of the right hand side into x. If x was already to declared to be an int64, E.G.:

var x int64

x := GetInt64()

Then the compiler complain that x is not new - it has already been declared. In this case you have to omit the colon to remove the fancy "auto" semantics.

var x int64

x = GetInt64()

That looks a lot like the old Pascal assignment vs equivalence operators. In Pascal (read Delphi) we had '=' for equality and ':=' for assignment. So:

x = 5 <-- a boolean statement, true if x equ 5

x := 5 <-- an assignment of the value 5 to the var x.

TBH, it's only like '=' vs '==' in C like languages. But it's easier to spot errors, as Pascal can never have a valid statement where the two are used in the wrong way.

Interesting. Seems I should take a look at Go.

You also usually declare stuff using this.

For example

    a := "hello"

or

    a := 0

or

    a := []byte{0, 1}

Implies the new variable's type to be the return type of the assigned expression.