3 ms·

I agree with you. And it would even be fine to allow shadowing but require an explicit declaration to allow it to happen in a particular case. e.g. import

I agree with you. And it would even be fine to allow shadowing but require an explicit declaration to allow it to happen in a particular case. e.g. import "foo" func other() { shadow var foo string = "bar"; }

masklinn 7y ago
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.
- zeeboo 7y ago
  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.
  - couchand 7y ago
    Well, in Rust you could do: let a = 2; let a = 3; I think you would say the latter shadows the former...
    - zeeboo 7y ago
      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.
- bboreham 7y ago
  That last one isn’t shadowing. := reuses a variable of the same name in the same scope.
rectang 7y ago
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".
- steveklabnik 7y ago
  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.
tfha 7y ago
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

masklinn 7y ago

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.

zeeboo 7y ago
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.
- couchand 7y ago
  Well, in Rust you could do: let a = 2; let a = 3; I think you would say the latter shadows the former...
  - zeeboo 7y ago
    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.
bboreham 7y ago
That last one isn’t shadowing. := reuses a variable of the same name in the same scope.

rectang 7y ago

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

steveklabnik 7y ago
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.

tfha 7y ago

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