FAQ
According to fmt Printing docs <http://golang.org/pkg/fmt/>, %#v prints "a
Go-syntax representation of the value".

Consider the following short Go program:

package main

import "fmt"

func main() {
x := [...]int{1,2, 3, 4, 5}
fmt.Printf("x := %#v\n", x)
}


If you run that .go source file through *gofmt*, you get:

package main

import "fmt"

func main() {
x := [...]int{1, 2, 3, 4, 5}
fmt.Printf("x := %#v\n", x)
}


Notice that the output of the fmt.Printf() statement matches the *gofmt*'ed
version of the variable definition in the source code.

Here are a few scenarios where the two (*gofmt*'ed source and output) match
perfectly:

Source: x := 42
Output: x := 42

Source: x := []int(nil)
Output: x := []int(nil)

Source: x := []int{1, 2, 3, 4, 5}
Output: x := []int{1, 2, 3, 4, 5}

Source: x := [5]int{1, 2, 3, 4, 5}
Output: x := [5]int{1, 2, 3, 4, 5}

Source: x := [...]int{1, 2, 3, 4, 5}
Output: x := [5]int{1, 2, 3, 4, 5} // Not a perfect match, but it makes
sense, and this line is valid Go which can be compiled

Now this is where we start to see a divergence:

Source: x := map[string]int{"mon": 0, "tue": 1, "wed": 2}
Output: x := map[string]int{"mon":0, "tue":1, "wed":2}
Output: x := map[string]int{"mon":0, "tue":1, "wed":2}
Output: x := map[string]int{"mon":0, "wed":2, "tue":1}

Note the inconsistency in the spacing. Is this intentional, or shouldn't
the spacing format output of %#v match that of gofmt here?

Running the above input many times gives random output in terms of the
strings order. Sometimes it's mon-tue-wed, or it could be tue-mon-wed, or
wed-tue-mon, etc. I suppose this is probably fine and has an obvious
logical explanation (although it would be good to confirm).

The same spacing inconsistency applies to structs:

type Lang struct {
Name string
Year int
URL string
}

Source: x := Lang{Name: "Go", Year: 2009, URL: "http"}
Output: x := main.Lang{Name:"Go", Year:2009, URL:"http"} // Invalid Go
code, doesn't compile

Again, note the inconsistency in spacing.

This time, there's another difference. "main." is prepended to the type in
the output, and this isn't valid Go code, it gives an error:

main.Lang undefined (type func() has no field or method Lang)


Anyway, my *main* question is this:

*1. Why is there an inconsistency in spacing after colons in gofmt and
fmt's %#v and %+v printing modes?*
*Is it on purpose, then what's the reason?*
*If not on purpose, does it mean it's unintended/bug, so when will it be
fixed?*
*
*
I'd also like to know:

2. How come the map example output doesn't preserve order? (I know the
answer is likely trivial, as in maps don't have a strict ordering, but I'd
like to have this confirmed)
3. Why is the package name and period ("main." in above example) prepended
in %#v output, yet it is invalid Go code?

Thank you!

--

Search Discussions

  • Dan Kortschak at Oct 18, 2012 at 5:31 am

    On Wed, 2012-10-17 at 22:12 -0700, Dmitri Shuralyov wrote:
    Anyway, my *main* question is this:

    I'd also like to know:

    2. How come the map example output doesn't preserve order? (I know the
    answer is likely trivial, as in maps don't have a strict ordering, but I'd
    like to have this confirmed)
    From http://golang.org/ref/spec#RangeClause:

    The iteration order over maps is not specified and is not guaranteed to
    be the same from one iteration to the next.
    3. Why is the package name and period ("main." in above example) prepended
    in %#v output, yet it is invalid Go code?
    Without the package identifier, the type description is not complete.
    You'll note that in gdb, main.Blah is valid.

    --
  • Dmitri Shuralyov at Oct 18, 2012 at 7:04 am

    On Thursday, October 18, 2012 1:31:21 AM UTC-4, kortschak wrote:
    On Wed, 2012-10-17 at 22:12 -0700, Dmitri Shuralyov wrote:
    I'd also like to know:

    2. How come the map example output doesn't preserve order? (I know the
    answer is likely trivial, as in maps don't have a strict ordering, but I'd
    like to have this confirmed)
    From http://golang.org/ref/spec#RangeClause:

    The iteration order over maps is not specified and is not guaranteed to
    be the same from one iteration to the next.
    Thank you! That's very clear and explicit (just like I anticipated).
    3. Why is the package name and period ("main." in above example)
    prepended
    in %#v output, yet it is invalid Go code?
    Without the package identifier, the type description is not complete.
    You'll note that in gdb, main.Blah is valid.
    That kinda makes sense. But why won't main.Lang{ ... } compile in Go
    itself, then?

    This mostly leaves my main question now... about the spacing.

    --
  • Dan Kortschak at Oct 18, 2012 at 10:28 am
    The main is implicit in the definition of the type because of the package the type was defined in. You can't define a package.Type outside package package, so there is no need for the package namespace to be specified. Since it's not needed, it's not allowed.
    On 18/10/2012, at 5:34 PM, "Dmitri Shuralyov" wrote:

    That kinda makes sense. But why won't main.Lang{ ... } compile in Go itself, then?
    --
  • Jan Mercl at Oct 18, 2012 at 8:09 am

    On Thursday, October 18, 2012 7:12:19 AM UTC+2, Dmitri Shuralyov wrote:

    Anyway, my *main* question is this:

    *1. Why is there an inconsistency in spacing after colons in gofmt and
    fmt's %#v and %+v printing modes?*
    *Is it on purpose, then what's the reason?*
    *If not on purpose, does it mean it's unintended/bug, so when will it be
    fixed?*
    B/c the %#v is not gofmt. Nowhere is documented that those two outputs
    should be same. The %#v is not intended for generating source code, but IMO
    as a convenience for debug prints. Actually %#v can never print fully
    correct Go source code as it lacks any knowledge about necessary context -
    e.g. when to use a package prefix and when not. To generate Go source code
    go/printer or equivalent machinery.

    *
    *
    I'd also like to know:

    2. How come the map example output doesn't preserve order? (I know the
    answer is likely trivial, as in maps don't have a strict ordering, but I'd
    like to have this confirmed)
    As others said already - map ranging order is specified to be non
    repeatable and is even intentionally made so in the runtime to catch early
    bugs rooted in relying on specific order.

    3. Why is the package name and period ("main." in above example) prepended
    in %#v output, yet it is invalid Go code?
    See #1. It is very useful for debugging.

    -j

    --
  • Dmitri Shuralyov at Oct 18, 2012 at 2:09 pm
    Thank you guys, questions 2 & 3 are clearly answered by now, so I'm going
    to focus on the main remaining question 1.
    On Thursday, October 18, 2012 4:09:21 AM UTC-4, Jan Mercl wrote:
    On Thursday, October 18, 2012 7:12:19 AM UTC+2, Dmitri Shuralyov wrote:

    Anyway, my *main* question is this:

    *1. Why is there an inconsistency in spacing after colons in gofmt and
    fmt's %#v and %+v printing modes?*
    *Is it on purpose, then what's the reason?*
    *If not on purpose, does it mean it's unintended/bug, so when will it be
    fixed?*
    B/c the %#v is not gofmt. Nowhere is documented that those two outputs
    should be same. The %#v is not intended for generating source code, but IMO
    as a convenience for debug prints. Actually %#v can never print fully
    correct Go source code as it lacks any knowledge about necessary context -
    e.g. when to use a package prefix and when not. To generate Go source code
    go/printer or equivalent machinery.
    Ok, let's drill down that answer please. I'm only going to talk about the *spacing
    inconsistency* here, the package names and whether it produces compilable
    code is left out (those questions are answered by now).

    Fair enough, it isn't documented that the outputs should be the same.
    However, they tend to be for the most part, so it seems a little odd when
    the pattern breaks.

    Are you suggesting that there's a good reason to purposefully keep the two
    spacing formats distinct? If so, I'd like to *understand* the reason so
    that this doesn't continue feeling like a minor bug to me.

    I still don't see one... I think it would be better if the spacing produced
    by %#v and %+v would match. Perhaps it's not a big deal, but that's not how
    improvements are supposed to be made (ignoring the insignificant issues).

    --
  • Dmitri Shuralyov at Oct 18, 2012 at 2:49 pm
    I just looked at src/pkg/fmt/print.go and as expected this would be a
    trivial change.

    http://golang.org/src/pkg/fmt/print.go?s=21667:21687#L852

    You'd just have to change the two occurrences of p.buf.WriteByte(':') (one
    under case reflect.Map:, the other under case reflect.Struct:) to
    p.buf.Write(colonSpaceBytes), and add var colonSpaceBytes = []byte(": ").
    Similarly to how there's already p.buf.Write(commaSpaceBytes) and var
    commaSpaceBytes = []byte(", ").

    Can anyone think of any good reasons to break the spacing pattern and *NOT*to put a space after the colon?

    --
  • Jan Mercl at Oct 18, 2012 at 3:52 pm

    On Thu, Oct 18, 2012 at 4:21 PM, Dmitri Shuralyov wrote:
    Can anyone think of any good reasons to break the spacing pattern and NOT to
    put a space after the colon?
    I can. Don't fix what's not broken. Also, the shorter a debug print is
    - the better.

    -j

    --
  • Dmitri Shuralyov at Oct 18, 2012 at 8:33 pm
    I can. Don't fix what's not broken.

    I'm sorry, but I think that's a lazy and counterproductive attitude. If
    someone proposes what he/she thinks is an improvement, it's better to
    consider both the existing situation and the proposed improvement, using
    logic, and try to find out which is the better solution, and implement it
    (if it's easy, else add it to tasks list for later). Just dismissing
    something because the current solution is deemed "good enough", even if the
    alternative might be slightly better, doesn't seem like the right thing to
    do IMO.

    Also, the shorter a debug print is - the better.


    Now this is a much better reason! This is what I want to hear.

    I think this is the better way to think about it. Having the space after
    colon vs. not having it has tradeoffs, *pros** & **cons*.

    The con of having space (conversely, the pro of not having it) is that
    debug prints get more verbose.
    The pro of having space is the extra consistency with the properly
    formatted Go syntax found everywhere else in Go.
    Are there any other tradeoffs?

    If there are no others, then it's a simple matter of figuring out which
    situation has the best overall score... I.e. Do we value consistency of
    formatting more? Or do we value shorter debug prints more. Or something in
    between?

    Because, as you can clearly see, %#v prints lists with spaces after commas,
    i.e. "[5]int{1, 2, 3, 4, 5}" and not "[5]int{1,2,3,4,5}" - despite the
    latter being shorter, and hence better according to your definition above.

    ---

    I'm here because I really like the Go language, and I want to make it
    better. Just like everyone else, I'm sure. Since I respond well to logic,
    I'd appreciate logical arguments that show something is better than other,
    rather than "just don't do anything because I said so".

    Right now I'm experiencing cognitive dissonance because what I think is the
    better solution (having spacing, being consistent) is not the way Go does
    it. So I'd like to either come to the conclusion that the way Golang does
    is is indeed better with logical reasons, OR that my proposed fix is the
    right way to go to improve the language (even if it's a very small, almost
    insignificant improvement on the grand scale of things... every bit helps,
    right? as long as it's an improvement). Thank you very much!

    --
  • Minux at Oct 18, 2012 at 3:53 pm

    On Oct 18, 2012 11:08 PM, "Dmitri Shuralyov" wrote:
    Right now I'm experiencing cognitive dissonance because what I think is
    the better solution (having spacing, being consistent) is not the way Go
    does it. So I'd like to either come to the conclusion that the way Golang
    does is is indeed better with logical reasons, OR that my proposed fix is
    the right way to go to improve the language (even if it's a very small,
    almost insignificant improvement on the grand scale of things... every bit
    helps, right? as long as it's an improvement). Thank you very much!
    this is not a bug, and people might already depend
    on that specific spacing (however unlikely), so according
    to go 1 api guarantee,
    we can't change it.
    i'm still not convinced why %#v or %+v should format
    exactly like gofmt, as if you want you can always reformat
    its output.

    --
  • Dmitri Shuralyov at Oct 18, 2012 at 5:21 pm
    this is not a bug,

    True. The fmt docs only say that %#v prints a "Go-syntax representation",
    it doesn't explicitly mention any spacing/formatting guarantees.

    and people might already depend on that specific spacing (however
    unlikely), so according to go 1 api guarantee, we can't change it.

    Also a true argument.

    Similar to the situation here<https://groups.google.com/forum/?fromgroups=#!starred/golang-nuts/Kle874lT1Eo>with missing rand.Uint64(), if it is deemed that this change would be an
    improvement, then an "issue" can be logged for go1.1 or go2 future
    consideration, is that correct?

    So it would look like this:

    http://code.google.com/p/go/issues/detail?id=4254

    i'm still not convinced why %#v or %+v should format exactly like gofmt,


    Fair enough. Here are my thoughts.

    I think it's a good idea to follow gofmt's spacing standard because of the
    consistency. It wouldn't be a drastic change from current behaviour.

    The main benefit I see is that it introduces a streamlined and consistent
    "spacing format" in go. gofmt is already the "go-to" source[1] for finding
    out how Go should be formatted, spacing-wise.

    For example, after gofmt, a function in go can maintain the format of "func
    myFunc() { Statement; }" or:

    func myFunc {
    Statement;
    }

    and nothing in between. This is a good thing for a language because it
    creates consistency between different developers. So when a new go
    developer joins your team, chances are his formatting style will match that
    of your existing codebase, and not cause conflicts like it would when there
    are mismatches (a situation common in other languages).

    So having a consistent and enforced formatting has a lot of value IMO. Once
    developers get used to gofmt'ed code, they tend to have a good idea of the
    formatting to use when writing their own code. So they never have to think
    about the minute details, like, do I put a space after a comma or not. Once
    they see a lot of "thing, thing, thing" examples they know you always put a
    space after a comma.

    In the case of colon, it seems to me so far that in gofmt'ed code there's
    always either a newline or a space after a colon. I haven't encountered any
    counter-examples.

    So the question IMO is whether these spacing formatting should apply to %#v
    and %+v which reportedly prints "Go-syntax representations". Again, since
    it's not a large change from the current output, I would say that *by
    default* %#v %+v should use gofmt's spacing conventions, and only break
    them if it is deemed absolutely necessary and offers a lot of value. The
    value offered by the missing spaces after colons right now, IMO, is not
    significant enough to diverge from the unified spacing format that's
    present otherwise.

    Well, that's my view on the situation. I'd like to know what others think...

    [1] http://golang.org/doc/effective_go.html Under the Formatting section.
    "If you want to know how to handle some new layout situation, run gofmt; if
    the answer doesn't seem right, rearrange your program (or file a bug about
    gofmt), don't work around it."

    I'd like to know what others think too.

    as if you want you can always reformat its output.
    >

    This is certainly true.

    --
  • Kamil Kisiel at Oct 18, 2012 at 6:13 pm

    On Thursday, October 18, 2012 9:13:58 AM UTC-7, Dmitri Shuralyov wrote:
    this is not a bug,


    True. The fmt docs only say that %#v prints a "Go-syntax representation",
    it doesn't explicitly mention any spacing/formatting guarantees.

    and people might already depend on that specific spacing (however
    unlikely), so according to go 1 api guarantee, we can't change it.

    Also a true argument.

    Similar to the situation here<https://groups.google.com/forum/?fromgroups=#!starred/golang-nuts/Kle874lT1Eo>with missing rand.Uint64(), if it is deemed that this change would be an
    improvement, then an "issue" can be logged for go1.1 or go2 future
    consideration, is that correct?

    So it would look like this:

    http://code.google.com/p/go/issues/detail?id=4254

    i'm still not convinced why %#v or %+v should format exactly like gofmt,


    Fair enough. Here are my thoughts.

    I think it's a good idea to follow gofmt's spacing standard because of the
    consistency. It wouldn't be a drastic change from current behaviour.

    The main benefit I see is that it introduces a streamlined and consistent
    "spacing format" in go. gofmt is already the "go-to" source[1] for finding
    out how Go should be formatted, spacing-wise.

    For example, after gofmt, a function in go can maintain the format of
    "func myFunc() { Statement; }" or:

    func myFunc {
    Statement;
    }

    and nothing in between. This is a good thing for a language because it
    creates consistency between different developers. So when a new go
    developer joins your team, chances are his formatting style will match that
    of your existing codebase, and not cause conflicts like it would when there
    are mismatches (a situation common in other languages).

    So having a consistent and enforced formatting has a lot of value IMO.
    Once developers get used to gofmt'ed code, they tend to have a good idea of
    the formatting to use when writing their own code. So they never have to
    think about the minute details, like, do I put a space after a comma or
    not. Once they see a lot of "thing, thing, thing" examples they know you
    always put a space after a comma.

    In the case of colon, it seems to me so far that in gofmt'ed code there's
    always either a newline or a space after a colon. I haven't encountered any
    counter-examples.

    So the question IMO is whether these spacing formatting should apply to
    %#v and %+v which reportedly prints "Go-syntax representations". Again,
    since it's not a large change from the current output, I would say that *by
    default* %#v %+v should use gofmt's spacing conventions, and only break
    them if it is deemed absolutely necessary and offers a lot of value. The
    value offered by the missing spaces after colons right now, IMO, is not
    significant enough to diverge from the unified spacing format that's
    present otherwise.

    Well, that's my view on the situation. I'd like to know what others
    think...

    [1] http://golang.org/doc/effective_go.html Under the Formatting section.
    "If you want to know how to handle some new layout situation, run gofmt; if
    the answer doesn't seem right, rearrange your program (or file a bug about
    gofmt), don't work around it."

    I'd like to know what others think too.

    as if you want you can always reformat its output.
    This is certainly true.

    What would happen in the case that it was desirable to change some of the
    formatting in gofmt for some reason, would the function need to change then
    too? I'm not sure if it's a good idea to couple them.

    --
  • Dmitri Shuralyov at Oct 18, 2012 at 5:14 pm

    What would happen in the case that it was desirable to change some of the
    formatting in gofmt for some reason, would the function need to change then
    too? I'm not sure if it's a good idea to couple them.

    This is a good point.

    As far as I understand it now, Go itself is primarily specified by its
    spec, not the implementation. So the spacing formatting must be coming from
    there too, right?

    Right now:

    Go spec -> gofmt code

    If the go spec changes, gofmt has to be updated to reflect that.

    I propose to add %#v and %+v, so

    Go spec -> gofmt code
    -> %#v and %+v code

    So a change to spec would require updating more code.

    Ideally, to reduce duplication of effort<http://alarmingdevelopment.org/?p=711>and automate what can be automated, in theory it could be done so that %#v
    and %+v code, as well as gofmt code, is generated directly from the go spec
    so that any updates to go spec would have gofmt and %#v/%+v printing using
    the new spacing format.

    With all that said, I think the spacing format doesn't change that often,
    and when it does, updating gofmt is already so much work, that updating
    %#v/%+v additionally would be insignificant extra work in comparison.

    --
  • Minux at Oct 18, 2012 at 6:54 pm

    On Oct 19, 2012 1:08 AM, "Dmitri Shuralyov" wrote:
    As far as I understand it now, Go itself is primarily specified by its
    spec, not the implementation. So the spacing formatting must be coming from
    there too, right
    no, go spec doesn't even mention gofmt.

    --
  • Dmitri Shuralyov at Oct 18, 2012 at 9:36 pm
    Interesting. So where does gofmt get its formatting rules from? Is it
    defined by the implementation of gofmt itself then?

    --
  • Minux at Oct 18, 2012 at 9:23 pm

    On Oct 19, 2012 1:18 AM, "Dmitri Shuralyov" wrote:
    Interesting. So where does gofmt get its formatting rules from? Is it
    defined by the implementation of gofmt itself then?
    the package go/printer.
    you can read gofmt's source code to be sure.

    tip.golang.org/src/cmd/gofmt/

    (in fact, large portion of gofmt's source is about
    rewrite, i.e. gofmt -r and simplification, i.e. gofmt -s)

    --
  • Dmitri Shuralyov at Oct 18, 2012 at 8:15 pm

    On Thursday, October 18, 2012 1:26:43 PM UTC-4, minux wrote:
    On Oct 19, 2012 1:18 AM, "Dmitri Shuralyov" wrote:
    Interesting. So where does gofmt get its formatting rules from? Is it
    defined by the implementation of gofmt itself then?
    the package go/printer.
    you can read gofmt's source code to be sure.

    tip.golang.org/src/cmd/gofmt/

    (in fact, large portion of gofmt's source is about
    rewrite, i.e. gofmt -r and simplification, i.e. gofmt -s)
    I see, thanks.

    Right now there are two spacing formats:

    1. One that comes from gofmt and related go/printer code.
    2. Another "Go-syntax representation" spacing format coming from fmt's
    %#v and %+v printing code.

    That's two separate formats, and I'm not sure why there has to be two
    instead of just one (the gofmt way). So there's an opportunity to simplify
    and reduce this to one formatting standard.

    I see three possible courses of action:

    1. In theory (this is something I haven't thought out in full detail,
    but I want to mention anyway), fmt's printing might be able to rely on
    go/printer code to take care of %#v and %+v printing, which would reduce
    code duplication. The huge downside of that, as far as I can tell, would be
    the performance. fmt's printing is likely several magnitudes faster than
    the gofmt / go/printer approach (something I haven't verified, just my
    intuition), making this impractical. (In addition, I'm not completely sure
    if go/printer can replace the functionality of %#v printing, since the
    former uses AST nodes to print and the latter uses reflection and real
    variables... so you might have to involve additional code, which further
    complicates things)
    2. Even if the code duplication is not eliminated (due to hugely
    different performance characteristics), the two spacing formats can still
    be merged into one by having fmt %#v and %+v spacing format follow that of
    gofmt.
    3. Finally, the last option is just to leave things as they are.

    I will be using go/printer for my task at hand, since it better suits my
    needs (and drop %#v), so this is just a matter of what's better for the
    language in the long run.

    It seems the last option is winning in popularity so far, but I just wanna
    make sure the other 2 get some exposure and get dismissed based on them
    being the wrong things to do.

    Thanks!

    --
  • U at Oct 18, 2012 at 10:27 pm
    For the record I think using one spacing format would be the correct
    long-term approach, mainly because consistency is far more valuable than
    beeing able to squeeze a few bytes in some cases.

    Regarding go1 promises, this issue could be created for future versions.
    Quality and consistency are very important for the Go language in the long
    run. An API promise is also important, to make the user base larger.

    Since go1 code is tagged as such it should be possible to commit a fix for
    this issue, and simply not tag that commit for go1?

    On Thursday, October 18, 2012 9:19:10 PM UTC+2, Dmitri Shuralyov wrote:
    On Thursday, October 18, 2012 1:26:43 PM UTC-4, minux wrote:
    On Oct 19, 2012 1:18 AM, "Dmitri Shuralyov" wrote:
    Interesting. So where does gofmt get its formatting rules from? Is it
    defined by the implementation of gofmt itself then?
    the package go/printer.
    you can read gofmt's source code to be sure.

    tip.golang.org/src/cmd/gofmt/

    (in fact, large portion of gofmt's source is about
    rewrite, i.e. gofmt -r and simplification, i.e. gofmt -s)
    I see, thanks.

    Right now there are two spacing formats:

    1. One that comes from gofmt and related go/printer code.
    2. Another "Go-syntax representation" spacing format coming from fmt's
    %#v and %+v printing code.

    That's two separate formats, and I'm not sure why there has to be two
    instead of just one (the gofmt way). So there's an opportunity to simplify
    and reduce this to one formatting standard.

    I see three possible courses of action:

    1. In theory (this is something I haven't thought out in full detail,
    but I want to mention anyway), fmt's printing might be able to rely on
    go/printer code to take care of %#v and %+v printing, which would reduce
    code duplication. The huge downside of that, as far as I can tell, would be
    the performance. fmt's printing is likely several magnitudes faster than
    the gofmt / go/printer approach (something I haven't verified, just my
    intuition), making this impractical. (In addition, I'm not completely sure
    if go/printer can replace the functionality of %#v printing, since the
    former uses AST nodes to print and the latter uses reflection and real
    variables... so you might have to involve additional code, which further
    complicates things)
    2. Even if the code duplication is not eliminated (due to hugely
    different performance characteristics), the two spacing formats can still
    be merged into one by having fmt %#v and %+v spacing format follow that of
    gofmt.
    3. Finally, the last option is just to leave things as they are.

    I will be using go/printer for my task at hand, since it better suits my
    needs (and drop %#v), so this is just a matter of what's better for the
    language in the long run.

    It seems the last option is winning in popularity so far, but I just wanna
    make sure the other 2 get some exposure and get dismissed based on them
    being the wrong things to do.

    Thanks!
    --
  • Dan Kortschak at Oct 18, 2012 at 11:33 pm
    On 19/10/2012, at 5:49 AM, "Dmitri Shuralyov" wrote:

    I see three possible courses of action:

    1. In theory (this is something I haven't thought out in full detail, but I want to mention anyway), fmt's printing might be able to rely on go/printer code to take care of %#v and %+v printing, which would reduce code duplication. The huge downside of that, as far as I can tell, would be the performance. fmt's printing is likely several magnitudes faster than the gofmt / go/printer approach (something I haven't verified, just my intuition), making this impractical. (In addition, I'm not completely sure if go/printer can replace the functionality of %#v printing, since the former uses AST nodes to print and the latter uses reflection and real variables... so you might have to involve additional code, which further complicates things)

    Have a look at the fmt code and see that this is really an overreaction to this 'problem'.

    1. Even if the code duplication is not eliminated (due to hugely different performance characteristics), the two spacing formats can still be merged into one by having fmt %#v and %+v spacing format follow that of gofmt.
    2. Finally, the last option is just to leave things as they are.

    Ding ding. As minux has said, there may be code that depends on the current output format. As it stands k:v pairs are more likely to be maintained as a unit when a line is split on white space, this, in the context of a unix environment, is a fairly significant behaviour since it means tools like cut can used to get these pairs. Now this is a silly little example, but it illustrates that what may be a trivial change can have significant downstream impact. You could argue that people using text processing on the output of a Go program are doing it wrong, since they could just alter the program itself, but the world is (successfully) built on people doing it wrong, and this would be broken for this aesthetic change.

    --

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedOct 18, '12 at 5:18a
activeOct 18, '12 at 11:33p
posts19
users6
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase