FAQ

On 02/19/2013 10:20 PM, minux wrote:

On Wed, Feb 20, 2013 at 5:14 AM, Johann Höchtl wrote:

On 02/19/2013 10:06 PM, minux wrote:


On Tue, Feb 19, 2013 at 3:20 PM, Johann Höchtl
wrote:

quick assignemnts, := , are meant to help the programmer
and give
the 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
<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(&notused)

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.

suppose we adopt this change, please write the update to the
spec page and
explain it as simple and as clear as possible.

The current spec is very precise, I wholeheartedly admit I am not
adept enough for that.

in what cases does the compiler give an error for shadowing? do
you need to
add some exceptions to your rules?


It would / should give an error if an "outer" variable is declared
but never assigned a value to it (but the default value) and
shadowed by an "inner" one.

Let's see this example:
found := true
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")
}

found is indeed assigned a value, however, this program is not correct but
according to your rule, the compiler won't detect it.
if you change := to = in the inner if clause, the program will work as
intended.
Absolutely. But it is very unlikely to specify the outer found as
found := true
which is exactly the reason why it would make sense that the compiler
would catch unassigned variables.
In case the address of the outer variable is somewhere taken, my
guess is that flow analysis would become to difficult (whole program
flow optimization), in which the compiler wouldn't report an error.
--
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.

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

People

Translate

site design / logo © 2021 Grokbase