<pre><code>package main
import "fmt"
func main() {
var foo int
for i, foo := 0, "Foo"; i < 1; i++ {
fmt.Println(i, foo)
}
fmt.Printf("%s", foo)
}
</code></pre>
<p>Here i have the <strong>foo</strong> var that is declared before the other <strong>foo</strong> inside the loop.</p>
<p>The behavior is correct due to scope, but i'd like to be warned if i have a variable with the same name (created with the <strong>:=</strong> construct) that the one declared with the <strong>var</strong> keyword before.</p>
<p>What do you think about that?</p>
<hr/>**评论：**<br/><br/>patrickdlogan: <pre><p>The vet tool can find shadowed variables. It cannot be a compile time error because sometimes shadowing is intentional.</p></pre>wubrgess: <pre><p>Is there a correct, succinct syntax to do what's expected in the above code snippet?</p></pre>Morgahl: <pre><p>Here:</p>
<pre><code>package main
import "fmt"
func main() {
var i int
var foo string
for i, foo = 0, "Foo"; i < 1; i++ {
fmt.Println(i, foo)
}
fmt.Printf("%s", foo)
}
</code></pre></pre>wubrgess: <pre><p>so there is not, thank you.</p></pre>dlsniper: <pre><p>There are many cases where shadowing is desired (or even needed) so having this powerful tool removed would do good to nobody.</p>
<p>Your example is one of many ways to have shadowing done. What if the code would be:</p>
<pre><code>for i := 0; i < 1; i++ {
foo := someOtherFunction()
fmt.Println(i, foo)
}
</code></pre>
<p>foo is declared inside the loop as well now. Should it be flagged or not?</p>
<p>Or in this case, where a function is shadowed?</p>
<pre><code>package main
func demo() {
println("this is a function")
}
func main() {
demo()
demo := "this is not a function anymore"
for i, demo := 0, "hello"; i < 10; i++ {
println(i, demo)
}
println(demo)
}
</code></pre>
<p>As <a href="/u/patrickdlogan" rel="nofollow">/u/patrickdlogan</a> pointed out, you can use <code>go vet -shadow</code> or <code>go vet -shadowstrict</code> to see some of the shadowed identifiers.</p>
<p>The next version of Gogland IDE will also support shadowing detection, disabled as using a separate algorithm and there's an ongoing discussion on how to make this better, see: <a href="https://youtrack.jetbrains.com/issue/GO-4403" rel="nofollow">https://youtrack.jetbrains.com/issue/GO-4403</a></p>
<p>Depending on the editor you are using there are various ways you can better spot shadowing, see the different color for example in Gogland: <a href="https://i.imgur.com/PCacLxz.png" rel="nofollow">https://i.imgur.com/PCacLxz.png</a></p>
<p>I don't think there's an algorithm that can detect shadowed identifiers without false positives and that is why this can never be in the compiler. As for warnings, the Go Team said they do not want to have warnings present the compiler so there's not much that can be done there.</p></pre>8lall0: <pre><p>Thanks for your answer.
I completely agree about shadowing (i use it a lot with the <strong>err</strong> checking); my only doubt is that it can create confusion if a shadowed variable has the same name of an upper variable.</p></pre>dlsniper: <pre><blockquote>
<p>my only doubt is that it can create confusion if a shadowed variable has the same name of an upper variable.</p>
</blockquote>
<p>You are contradicting yourself in the same sentence while describing exactly how shadowing works:</p>
<blockquote>
<p>I completely agree about shadowing (i use it a lot with the err checking)</p>
</blockquote>
<p>And if you completely agree about shadowing, and you supposedly know all of this already, why would you propose something that you know it's not good? And have you seen the previous threads here or on golang-nuts about the very same problem? Unless there's anything new that I'm missing then this is pretty much a rehash of all those previous threads and it will also lead to the same point: nowhere.</p></pre>
