Compilers know types better than humans.
Whoever bans it (whithout a very, very compelling reason like "some of our code has to compile in an old compiler") is being a luddite at best.
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.
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.
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;
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.
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.
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()
For example
a := "hello"
a := 0
a := []byte{0, 1}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.