FAQ
Normally, if I have some free variable that's already been declared, I can
have it on the left side of := as long as at least one other variable on
the LHS has not been declared, for instance

var a int
// ...
a,err := DoSomething()
// ...

I recently found out this apparently doesn't work with struct fields

var x SomeStruct
x.a,err := DoSomething()

(Playground: http://play.golang.org/p/qidzSkDbzA )

If it's just an "=" operator and you forward declare err, it works just fine

var x SomeStruct
var err error
x.a,err = DoSomething()

(Playground: http://play.golang.org/p/IlIUERzbk6 )

It's kind of obnoxious, honestly. Is there a good reason for it? Does it
complicate the grammar too much to allow this? I mean, it only takes a few
extra lines (depending on how many LHS variables you have), so it's not the
end of the world to work around it, but I don't really see a rationale for
not allowing this. I can see someone making the argument "you can never
declare a struct field, therefore a struct field has no business on the LHS
of a short form variable declaration", but given that non-declarations are
already allowed on the LHS of one, it feels inconsistent to not allow
struct fields there under the same rules as already-declared variables
(that is: at least one other variable must actually be a declaration).

Again, it's not a huge deal, but I would like to understand the rationale.

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

  • Minux at Jan 24, 2014 at 5:51 am

    On Fri, Jan 24, 2014 at 12:42 AM, Jsor wrote:

    Normally, if I have some free variable that's already been declared, I can
    have it on the left side of := as long as at least one other variable on
    the LHS has not been declared, for instance

    var a int
    // ...
    a,err := DoSomething()
    // ...

    I recently found out this apparently doesn't work with struct fields

    var x SomeStruct
    x.a,err := DoSomething()

    (Playground: http://play.golang.org/p/qidzSkDbzA )

    If it's just an "=" operator and you forward declare err, it works just
    fine

    var x SomeStruct
    var err error
    x.a,err = DoSomething()

    (Playground: http://play.golang.org/p/IlIUERzbk6 )

    It's kind of obnoxious, honestly. Is there a good reason for it? Does it
    complicate the grammar too much to allow this? I mean, it only takes a few
    extra lines (depending on how many LHS variables you have), so it's not the
    end of the world to work around it, but I don't really see a rationale for
    not allowing this. I can see someone making the argument "you can never
    declare a struct field, therefore a struct field has no business on the LHS
    of a short form variable declaration", but given that non-declarations are
    already allowed on the LHS of one, it feels inconsistent to not allow
    struct fields there under the same rules as already-declared variables
    (that is: at least one other variable must actually be a declaration).

    Again, it's not a huge deal, but I would like to understand the rationale
    There is https://code.google.com/p/go/issues/detail?id=6842 for this issue.

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

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedJan 24, '14 at 5:42a
activeJan 24, '14 at 5:51a
posts2
users2
websitegolang.org

2 users in discussion

Minux: 1 post Jsor: 1 post

People

Translate

site design / logo © 2022 Grokbase