Or only allow shadowing for `var` and forbid it for `:=`[0]. Though forbidding it entirely would work just as well.

[0] and go is actually weirder than that — and the opposite way 'round — as `var` doesn't allow any shadowing in the same scope:

    var a, b int
    var a, c int // fails because it redeclares a in the same block

while `:=` allows same-scope shadowing as long as the overlap is not complete:

    a, b := foo()
    a, b := foo() // fails because no new variable on the left side
    a, c := foo() // succeeds

both allow arbitrary shadowing in sub-scopes.

There's no shadowing in the latter case. The second case is the same thing as

    a := 2
    a = 3

By definition you must have nested scopes to have shadowing. Within the same scope, it's only ever assignment.

Well, in Rust you could do:

    let a = 2;
    let a = 3;

I think you would say the latter shadows the former...

Indeed, because semantically there is a syntactically implicit scope for every let binding. For example, in that case, the outer a is dropped after the inner a, just as if the second a had been inside of a block. There may be multiple syntactic ways to introduce a new scope.

That last one isn’t shadowing. := reuses a variable of the same name in the same scope.

I'm honestly of the opinion that this shouldn't be allowed either. Accept that you need to name the variable 'fooErr' and just ban all shadowing

I really like this syntax. I wonder if it has ever been proposed for Rust? It should be compatible with the existing semantics and could be phased in and then made mandatory in a new "edition".

It has, but hasn’t gained much traction.

There is already a “let” to show you that a variable is being created, adding more verbosity to a feature that, in some sense, is about removing verbosity kinda misses the point, in my opinion.

That said, never say never, but if I was a betting kind of person, I’d bet against it ever being accepted.