FAQ
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

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.

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.

Search Discussions

  • Jan Mercl at Feb 21, 2013 at 8:58 pm
    The forgotten things about recursion and in-loop declarations are referring
    to the previously discussed thought experiment with TLD transformation,
    where Thomas correctly pointed out it would destroy proper recursive calls.
    And also loop local declarations (b/c of the zero value not being effective
    in every pass anymore).

    -j

    --
    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.
  • Nate Finch at Feb 21, 2013 at 3:16 pm
    This is more about the fact that code becomes much less portable, and can
    later become invalid because of a top level import:

    func a() {
    math := "is hard"
    fmt.Println(math)
    }

    If you later import "math" into this file, this function suddenly becomes
    invalid if you can't shadow. Since anyone can name imports whatever they
    want, this could be a huge pain (yes you could rename the import).



    On Thursday, February 21, 2013 9:09:52 AM UTC-5, Patrick Mylund Nielsen
    wrote:
    A "var oa int" would still be in block scope.


    On Thu, Feb 21, 2013 at 2:58 PM, Jan Mercl <0xj...@gmail.com <javascript:>
    wrote:
    On Thu, Feb 21, 2013 at 2:38 PM, Patrick Mylund Nielsen
    <pat...@patrickmylund.com <javascript:>> wrote:
    I would propose another radical solution for this: Simply that
    shadowing
    variables is not allowed.
    Good bye block scoping.
    Block scoping does not disappear if you can't declare new variables with
    names identical to variables in outer scopes.
    package main
    var a int
    func main() {
    var a int // main.go:4: a redeclared in this block previous
    declaration at main.go:2

    ...
    }

    Well, is it just me who doesn't call the above 'block scoping' anymore?

    -j
    --
    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.
  • John Nagle at Feb 21, 2013 at 11:43 pm

    On 2/21/2013 7:16 AM, Nate Finch wrote:
    If you later import "math" into this file, this function suddenly becomes
    invalid if you can't shadow. Since anyone can name imports whatever they
    want, this could be a huge pain (yes you could rename the import).
    "import" only brings in upper case variables, right? (Except for
    the module name itself.)

    John Nagle

    --
    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.
  • Nate Finch at Feb 22, 2013 at 12:11 am
    Sorry, terrible example... I meant something like this:

    http://play.golang.org/p/FrcUIT21Go

    type M struct{}

    func (m M) Max() int {
    return 5
    }

    func foo() {
    math := M{}
    fmt.Println(math.Max())
    }

    If shadowing didn't work, importing math would suddenly break this program.
    On Thursday, February 21, 2013 6:34:46 PM UTC-5, John Nagle wrote:
    On 2/21/2013 7:16 AM, Nate Finch wrote:
    If you later import "math" into this file, this function suddenly becomes
    invalid if you can't shadow. Since anyone can name imports whatever they
    want, this could be a huge pain (yes you could rename the import).
    "import" only brings in upper case variables, right? (Except for
    the module name itself.)

    John Nagle
    --
    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.
  • Patrick Mylund Nielsen at Feb 22, 2013 at 12:13 am
    I'm not convinced this is a real problem. You usually don't use names of
    packages you have imported (and are using!) anyway.

    On Fri, Feb 22, 2013 at 1:11 AM, Nate Finch wrote:

    Sorry, terrible example... I meant something like this:

    http://play.golang.org/p/FrcUIT21Go

    type M struct{}

    func (m M) Max() int {
    return 5
    }

    func foo() {
    math := M{}
    fmt.Println(math.Max())
    }

    If shadowing didn't work, importing math would suddenly break this program.
    On Thursday, February 21, 2013 6:34:46 PM UTC-5, John Nagle wrote:
    On 2/21/2013 7:16 AM, Nate Finch wrote:
    If you later import "math" into this file, this function suddenly becomes
    invalid if you can't shadow. Since anyone can name imports whatever they
    want, this could be a huge pain (yes you could rename the import).
    "import" only brings in upper case variables, right? (Except for
    the module name itself.)

    ** John Nagle

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

    --
    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.
  • Nate Finch at Feb 22, 2013 at 12:25 am
    My point was about adding an import *after* writing a lot of code (when
    adding features or whatever), and that without shadowing, merely importing
    a package now has the potential to break existing code....

    The current shadowing rules insulate code inside functions from what
    happens at the top level of the file, so that adding imports to the file
    will never break existing code (now waiting for someone to prove me wrong
    on this ;)

    On Thursday, February 21, 2013 7:13:35 PM UTC-5, Patrick Mylund Nielsen
    wrote:
    I'm not convinced this is a real problem. You usually don't use names of
    packages you have imported (and are using!) anyway.

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

Related Discussions

People

Translate

site design / logo © 2019 Grokbase