language the feeling being a duck-typed, dynamic language yet with the
powers of static type checking. Unfortunately this feature comes at the
price of introducing nasty, hard to spot shadowing bugs.
Consider this program:
http://play.golang.org/p/nroI2nSKyG
package main
import "fmt"
func answertoeverything(idx int) bool {
return true
}
func main() {
var answer string
var found bool
for idx := range []int{1, 3, 5} {
if found := answertoeverything(idx); found == true {
answer = "We got an answer"
break
}
}
if found {
fmt.Println("The answer is", answer)
} else {
fmt.Println("No answer was found")
}
}
The variable "found" is hidden. This is clearly a mistake yet get's
unspotted by the current compiler. This is either a plain bug, or, if not,
I suppose to change the behaviour in that simply accessing a variable is
not enough to silence the compiler, but either assigning to it or taking
it'd address.
_ := silence
is seen very often and suffices to calm the compiler. I would suggest, that
only a proper assignment can silence the "introduced but not used" error,
or taking the address of such a variable as eg. in
callfunc(¬used)
Thus
_ := silence
would become
_ := &silence
If this variable get's actually used at a a later point, it is most likely
that it will not be used in a pointer context, in such as the programmer
can still benefit from the compilers analysis.
Johann
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.