FAQ
Compare line 6 and line 8 in this code
(http://play.golang.org/p/87_nThcN-R):

package main

func main() {
for _, x := range []struct {
in, out int
}{
{1, 1},
} {
if x.in != x.out {
// problems...
}
}
}

Is there a reason why gofmt puts a space between the curly brackets on line
8 but not on line 6?

--

Search Discussions

  • Jan Mercl at Jan 16, 2013 at 1:01 pm
    On Wed, Jan 16, 2013 at 1:54 PM, Stefan Nilsson wrote:
    I think it's okay: http://play.golang.org/p/Mwrr0LZEht

    -j

    --
  • Kevin Gillette at Jan 16, 2013 at 3:13 pm
    Semantically they're different: the one without the space is an anonymous
    struct literal, while the one with the space marks the end of the struct
    literal and the beginning of the loop.

    Anyways, this isn't even a syntactical corner-case -- the dimensionality is
    too high, and in a year of working with Go, this is the first I've seen of
    a range loop over an anonymous struct's anonymous literal value.
    On Wednesday, January 16, 2013 5:54:23 AM UTC-7, Stefan Nilsson wrote:

    Compare line 6 and line 8 in this code (
    http://play.golang.org/p/87_nThcN-R):

    package main

    func main() {
    for _, x := range []struct {
    in, out int
    }{
    {1, 1},
    } {
    if x.in != x.out {
    // problems...
    }
    }
    }

    Is there a reason why gofmt puts a space between the curly brackets on
    line 8 but not on line 6?
    --
  • Stefan Nilsson at Jan 16, 2013 at 5:50 pm
    Itʼs not a corner case for me – this pattern comes up in pretty much all
    test code Iʼve ever written in Go. In table-driven tests, I find it
    convenient to use an anonymous struct to describes the input and expected
    output. However, the spacing surely is a very minor issue; perhaps it would
    make sense to add a space in this case, or perhaps not. I really canʼt tell.
    On Wednesday, January 16, 2013 4:13:20 PM UTC+1, Kevin Gillette wrote:

    Semantically they're different: the one without the space is an anonymous
    struct literal, while the one with the space marks the end of the struct
    literal and the beginning of the loop.

    Anyways, this isn't even a syntactical corner-case -- the dimensionality
    is too high, and in a year of working with Go, this is the first I've seen
    of a range loop over an anonymous struct's anonymous literal value.
    On Wednesday, January 16, 2013 5:54:23 AM UTC-7, Stefan Nilsson wrote:

    Compare line 6 and line 8 in this code (
    http://play.golang.org/p/87_nThcN-R):

    package main

    func main() {
    for _, x := range []struct {
    in, out int
    }{
    {1, 1},
    } {
    if x.in != x.out {
    // problems...
    }
    }
    }

    Is there a reason why gofmt puts a space between the curly brackets on
    line 8 but not on line 6?
    --
  • Sonia Keys at Jan 16, 2013 at 6:37 pm
    I also use this pattern but I never worried about the formatting. I just
    let gofmt do its thing.

    --
  • Kevin Gillette at Jan 16, 2013 at 8:20 pm
    Fair enough. I've always has enough data to stuff in my tests that theelement structs are pretty thick, and multiple test funcs per table are warranted, so this style always managed to avoid itself in my case.

    --
  • Andrew Gerrand at Jan 17, 2013 at 6:58 am

    On 17 January 2013 04:50, Stefan Nilsson wrote:

    However, the spacing surely is a very minor issue; perhaps it would make
    sense to add a space in this case, or perhaps not. I really canʼt tell.

    It absolutely makes sense

    It's clear, looking at the following code, that there should a space
    between the []string literal and the for block's opening brace.

    for _ = range []string{"foo"} {
    }

    The same rule applies to your anonymous struct literal.

    Andrew

    --
  • Kevin Gillette at Jan 17, 2013 at 9:42 am
    Though in your example, the literal's parens are on the same line as the
    loop's opening paren; in the "unnamed slice of unnamed struct type
    anonymous value literal" case, the 'for' keyword can be pages away from its
    opening paren. Stylistically, it doesn't really make sense for the tokens
    between 'range' and '{' to potentially dwarf the loop body, particularly in
    the number of lines involved. If the use case wasn't testing, I'd quickly
    dismiss it as pernicious (just as I would
    with http://play.golang.org/p/6-oOlgSAYU).
    On Wednesday, January 16, 2013 11:58:12 PM UTC-7, Andrew Gerrand wrote:


    On 17 January 2013 04:50, Stefan Nilsson <trollerip...@gmail.com<javascript:>
    wrote:
    However, the spacing surely is a very minor issue; perhaps it would make
    sense to add a space in this case, or perhaps not. I really canʼt tell.

    It absolutely makes sense

    It's clear, looking at the following code, that there should a space
    between the []string literal and the for block's opening brace.

    for _ = range []string{"foo"} {
    }

    The same rule applies to your anonymous struct literal.

    Andrew
    --
  • Dan Kortschak at Jan 16, 2013 at 7:43 pm
    I use this pattern a lot in tests and you'll see it used similaryly in the std lib.

    The difference in spacing, as Jan has said, is consistent. An more, it's helpful, with two and two half lines of braces, without differentiation it would be unclear what the grouping is without the spacing as it is.
    On 17/01/2013, at 1:43 AM, "Kevin Gillette" wrote:

    Semantically they're different: the one without the space is an anonymous struct literal, while the one with the space marks the end of the struct literal and the beginning of the loop.

    Anyways, this isn't even a syntactical corner-case -- the dimensionality is too high, and in a year of working with Go, this is the first I've seen of a range loop over an anonymous struct's anonymous literal value.
    --
  • Kyle Lemons at Jan 16, 2013 at 8:41 pm
    Usually I put the tests in a variable:

    tests := []struct{
    ...
    }{
    ...
    }

    for _, test := range tests {

    }
    On Wed, Jan 16, 2013 at 11:43 AM, Dan Kortschak wrote:

    I use this pattern a lot in tests and you'll see it used similaryly in the
    std lib.

    The difference in spacing, as Jan has said, is consistent. An more, it's
    helpful, with two and two half lines of braces, without differentiation it
    would be unclear what the grouping is without the spacing as it is.
    On 17/01/2013, at 1:43 AM, "Kevin Gillette" wrote:

    Semantically they're different: the one without the space is an
    anonymous struct literal, while the one with the space marks the end of the
    struct literal and the beginning of the loop.
    Anyways, this isn't even a syntactical corner-case -- the dimensionality
    is too high, and in a year of working with Go, this is the first I've seen
    of a range loop over an anonymous struct's anonymous literal value.

    --

    --
  • Bryanturley at Jan 16, 2013 at 8:26 pm

    On Wednesday, January 16, 2013 6:54:23 AM UTC-6, Stefan Nilsson wrote:
    Compare line 6 and line 8 in this code (
    http://play.golang.org/p/87_nThcN-R):

    package main

    func main() {
    for _, x := range []struct {
    in, out int
    }{
    {1, 1},
    } {
    if x.in != x.out {
    // problems...
    }
    }
    }

    Is there a reason why gofmt puts a space between the curly brackets on
    line 8 but not on line 6?
    What I want to know is why would you write something that looks like that.
    Stick that struct in a variable before the for loop.


    --
  • Dan Kortschak at Jan 16, 2013 at 8:30 pm
    Why? If the table is only used in one place this is very clear.
    On 17/01/2013, at 6:56 AM, "bryanturley" wrote:

    What I want to know is why would you write something that looks like that.
    Stick that struct in a variable before the for loop.
    --
  • Kevin Gillette at Jan 16, 2013 at 9:48 pm
    Sure, but it may not be clear at all to a first time reader, since
    programmers may optimally read code in random-access-order -- a named value
    literal without wrapping parens is a syntax error
    (ambiguity). http://play.golang.org/p/eE9-6pRwp3

    I will grant that after seeing the pattern enough times, it becomes
    reasonably easy to recognize and spot read, though imo, a bit hairy (for
    clarity, like bryanturley, I would just spend the extra two lines and use a
    variable).
    On Wednesday, January 16, 2013 1:30:42 PM UTC-7, kortschak wrote:

    Why? If the table is only used in one place this is very clear.

    On 17/01/2013, at 6:56 AM, "bryanturley" <bryan...@gmail.com <javascript:>>
    wrote:
    What I want to know is why would you write something that looks like that.
    Stick that struct in a variable before the for loop.
    --
  • Dan Kortschak at Jan 16, 2013 at 9:03 pm
    The idiomatic approach is to use a struct definition in place which avoids that possible syntactic ambiguity since it is led by [].
    On 17/01/2013, at 7:16 AM, "Kevin Gillette" wrote:

    Sure, but it may not be clear at all to a first time reader, since programmers may optimally read code in random-access-order -- a named value literal without wrapping parens is a syntax error (ambiguity). http://play.golang.org/p/eE9-6pRwp3
    --
  • Kevin Gillette at Jan 16, 2013 at 9:13 pm
    Any stdlib or official blog/docs instances of this idiom, by chance?
    On Wednesday, January 16, 2013 1:54:57 PM UTC-7, kortschak wrote:

    The idiomatic approach is to use a struct definition in place which avoids
    that possible syntactic ambiguity since it is led by [].
    On 17/01/2013, at 7:16 AM, "Kevin Gillette" wrote:

    Sure, but it may not be clear at all to a first time reader, since
    programmers may optimally read code in random-access-order -- a named value
    literal without wrapping parens is a syntax error (ambiguity).
    http://play.golang.org/p/eE9-6pRwp3
    --
  • Dan Kortschak at Jan 16, 2013 at 9:27 pm
    Less prevalent than I had expected, though inline type definition is very common, e.g. fmt tests.

    sql/sql_test.go:256
    json/tags_test.go:16

    On 17/01/2013, at 7:43 AM, "Kevin Gillette" wrote:

    Any stdlib or official blog/docs instances of this idiom, by chance?

    On Wednesday, January 16, 2013 1:54:57 PM UTC-7, kortschak wrote:
    The idiomatic approach is to use a struct definition in place which avoids that possible syntactic ambiguity since it is led by [].
    On 17/01/2013, at 7:16 AM, "Kevin Gillette" wrote:

    Sure, but it may not be clear at all to a first time reader, since programmers may optimally read code in random-access-order -- a named value literal without wrapping parens is a syntax error (ambiguity). http://play.golang.org/p/eE9-6pRwp3
    --


    --
  • Jan Mercl at Jan 16, 2013 at 8:38 pm

    On Jan 16, 2013 9:26 PM, "bryanturley" wrote:
    What I want to know is why would you write something that looks like that.
    Stick that struct in a variable before the for loop.
    A variable assigned only once; and also read-referenced only once
    afterwards, is semantically equal to using a literal value of the same type
    instead.

    -j

    --
  • Bryanturley at Jan 16, 2013 at 8:43 pm

    On Wednesday, January 16, 2013 2:38:36 PM UTC-6, Jan Mercl wrote:

    On Jan 16, 2013 9:26 PM, "bryanturley" <bryan...@gmail.com <javascript:>>
    wrote:
    What I want to know is why would you write something that looks like that.
    Stick that struct in a variable before the for loop.
    A variable assigned only once; and also read-referenced only once
    afterwards, is semantically equal to using a literal value of the same type
    instead.

    -j
    Well I was referring to the aesthetics of it, not the functionality.
    I will type a few more lines if it becomes more readable.

    --
  • Dan Kortschak at Jan 16, 2013 at 8:56 pm
    That conditional is the key to this decision.
    On 17/01/2013, at 7:14 AM, "bryanturley" wrote:

    I will type a few more lines if it becomes more readable.
    --
  • Rory McGuire at Jan 17, 2013 at 5:19 am
    Surely your struct should be a const with a decent label.
    That code looks particularly ugly. Imagine is even worse if it's got a little more coffee in the loop.

    My 2c. I get the literal is used only once but the legibility suffers in this particular case.

    --

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedJan 16, '13 at 12:54p
activeJan 17, '13 at 9:42a
posts20
users9
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase