FAQ
I know it can't happen until the (mythic) Go2 (considered harmful?) but I
think shadowing and simple assignment would work better if they followed
these rules:

1) A name declared in a var or function statement (i.e parameters and named
results) cannot be shadowed.
2) A name declared in a simple assignment statement can be shadowed.
3) A name declared in a var or function statement can be assigned to by a
simple assignment only if a new name is also declared in that statement.

In my experience shadowing function parameters or results is error prone.
  Making var declared name unshadowable lets us have the compiler detect
variables shadowed in error.

These rules also let us replace:

func fx( x int ) ( y int ) {
      var e error
      if ( y, e = fn(x); e != nil {
        <do somethibg with e>
      }
      return
}

with:

func fx( x int ) ( y int ) {
     if ( y, e := fn(x); e != nil {
         <do somethibg with e>
     }
     return
}

Minor, but I trip over this fairly regularly, writing it the second way and
having to add the var statement/

I'm curious if anyone can see some useful idiom that the actual Go rules
allow that this would prevent. I can't, but that may just be my coding
style.

Jonathan

--
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/d/optout.

Search Discussions

  • Tamás Gulácsi at Apr 22, 2016 at 4:04 am
    func fx( x int ) ( y int ) {
         y, e := fn(x)
         if e != nil {
             <do sometibg with e>
         }
         return
    }

    --
    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/d/optout.
  • Jonathan at Apr 22, 2016 at 12:40 pm
    Yup, or that. My desire is to prevent the shadowing in the first place.

    Jonathan
    On Friday, April 22, 2016 at 12:04:44 AM UTC-4, Tamás Gulácsi wrote:

    func fx( x int ) ( y int ) {
    y, e := fn(x)
    if e != nil {
    <do sometibg with e>
    }
    return
    }
    --
    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/d/optout.
  • Nick Craig-Wood at Apr 22, 2016 at 1:04 pm
    While we are waiting for Go 2 you might find

    go tool vet -shadow .

    or

    go tool vet -shadow -shadowstrict .

    interesting!
    On 22/04/16 01:22, Jonathan wrote:

    I know it can't happen until the (mythic) Go2 (considered harmful?) but
    I think shadowing and simple assignment would work better if they
    followed these rules:

    1) A name declared in a var or function statement (i.e parameters and
    named results) cannot be shadowed.
    2) A name declared in a simple assignment statement can be shadowed.
    3) A name declared in a var or function statement can be assigned to by
    a simple assignment only if a new name is also declared in that statement.

    In my experience shadowing function parameters or results is error
    prone. Making var declared name unshadowable lets us have the compiler
    detect variables shadowed in error.

    These rules also let us replace:

    func fx( x int ) ( y int ) {
    var e error
    if ( y, e = fn(x); e != nil {
    <do somethibg with e>
    }
    return
    }

    with:

    func fx( x int ) ( y int ) {
    if ( y, e := fn(x); e != nil {
    <do somethibg with e>
    }
    return
    }

    Minor, but I trip over this fairly regularly, writing it the second way
    and having to add the var statement/

    I'm curious if anyone can see some useful idiom that the actual Go rules
    allow that this would prevent. I can't, but that may just be my coding
    style.

    Jonathan
    --
    Nick Craig-Wood <nick@craig-wood.com> -- http://www.craig-wood.com/nick

    --
    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/d/optout.
  • Jonathan at Apr 22, 2016 at 1:44 pm
    Thanks, I do. When I have some time I'll see if I can make something that
    vets my "rules".

    Jonathan
    On Friday, April 22, 2016 at 9:04:25 AM UTC-4, Nick Craig-Wood wrote:

    While we are waiting for Go 2 you might find

    go tool vet -shadow .

    or

    go tool vet -shadow -shadowstrict .

    interesting!
    On 22/04/16 01:22, Jonathan wrote:

    I know it can't happen until the (mythic) Go2 (considered harmful?) but
    I think shadowing and simple assignment would work better if they
    followed these rules:

    1) A name declared in a var or function statement (i.e parameters and
    named results) cannot be shadowed.
    2) A name declared in a simple assignment statement can be shadowed.
    3) A name declared in a var or function statement can be assigned to by
    a simple assignment only if a new name is also declared in that
    statement.
    In my experience shadowing function parameters or results is error
    prone. Making var declared name unshadowable lets us have the compiler
    detect variables shadowed in error.

    These rules also let us replace:

    func fx( x int ) ( y int ) {
    var e error
    if ( y, e = fn(x); e != nil {
    <do somethibg with e>
    }
    return
    }

    with:

    func fx( x int ) ( y int ) {
    if ( y, e := fn(x); e != nil {
    <do somethibg with e>
    }
    return
    }

    Minor, but I trip over this fairly regularly, writing it the second way
    and having to add the var statement/

    I'm curious if anyone can see some useful idiom that the actual Go rules
    allow that this would prevent. I can't, but that may just be my coding
    style.

    Jonathan
    --
    Nick Craig-Wood <ni...@craig-wood.com <javascript:>> --
    http://www.craig-wood.com/nick
    --
    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/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedApr 22, '16 at 12:22a
activeApr 22, '16 at 1:44p
posts5
users3
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase