4 ms·

Go authors have explicitly stated that while the branches are clunky, they are so intentionally to make the points where your code branches much more obvious.

Go authors have explicitly stated that while the branches are clunky, they are so intentionally to make the points where your code branches much more obvious. I wasn't sold at first, but 6 months ago I decided to use it for a project where it's ease of cross-compilation was the deciding factor, and since then I have to agree. Anyways, you're entirely free to use a named return value in the second (or later) part of a multi valued := statement. An example is noted below, the clunky and obvious branches are there, but the intent and flow is obvious at a glance. Example: https://play.golang.org/p/56Jv9Cvrw-s https://play.golang.org/p/56Jv9Cvrw-s

unscaled 5y ago
The "Go authors" (by that I assume you mean the Go team) have very explicitly stated that they view the current way Go does error handling as a major problem[1][2]. [1] https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md https://go.googlesource.com/proposal/+/master/design/go2draf... [2] https://github.com/golang/go/issues/32437#issuecomment-512035919 https://github.com/golang/go/issues/32437#issuecomment-51203...
- akira2501 5y ago
  I was referring to what is written in "Effective Go" which seems to contradict [1] on style. Effective Go, on if: https://golang.org/doc/effective_go#if https://golang.org/doc/effective_go#if
  - unscaled 5y ago
    The section that you're linking to in Effective Go does not state anywhere that "branches are clunky, they are so intentionally to make the points where your code branches much more obvious". It only promotes the concept that of using guard-clause style ifs that return an error and have no else clause, gradually eliminating each possible error condition. This style of programming was later termed in the Go community "Aligning the happy path to the left"[1][2] [1] https://medium.com/@matryer/line-of-sight-in-code-186dd7cdea88 https://medium.com/@matryer/line-of-sight-in-code-186dd7cdea... [2] https://maelvls.dev/go-happy-line-of-sight/ https://maelvls.dev/go-happy-line-of-sight/ I wholeheartedly agree that this style makes code more readable and I have adopted it - and encouraged others to adopt it - in other languages besides Go. This style would stil be followed with the try or check/handle proposals. For instance, let's take the example: f, err := os.Open(name) if err != nil { return err } d, err := f.Stat() if err != nil { f.Close() return err } codeUsing(f, d) f.Close() return nil With the simple try proposal that would be: f := try(os.Open(name)) defer f.Close() d := try(f.Stat()) codeUsing(f, d) With OP's variant of the try proposal, using a question mark this is arguably even more readable (less noisy): f := os.Open(name)? defer f.Close() d := f.Stat()? codeUsing(f, d) As you can see, these proposal reduce - not increase - nesting, so they are completely in line with what Effective Go is saying.
    - sagichmal 5y ago
      You continue to assert that error handling adds noise to a block of code. This is an opinion, that's fine, but it's not an objective truth. In many many domains -- in fact the domains which Go targets -- error handling is equally important to business logic.
- sagichmal 5y ago
  That is not at all what those links indicate.

unscaled 5y ago

The "Go authors" (by that I assume you mean the Go team) have very explicitly stated that they view the current way Go does error handling as a major problem[1][2]. [1] https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md https://go.googlesource.com/proposal/+/master/design/go2draf... [2] https://github.com/golang/go/issues/32437#issuecomment-512035919 https://github.com/golang/go/issues/32437#issuecomment-51203...

akira2501 5y ago
I was referring to what is written in "Effective Go" which seems to contradict [1] on style. Effective Go, on if: https://golang.org/doc/effective_go#if https://golang.org/doc/effective_go#if
- unscaled 5y ago
  The section that you're linking to in Effective Go does not state anywhere that "branches are clunky, they are so intentionally to make the points where your code branches much more obvious". It only promotes the concept that of using guard-clause style ifs that return an error and have no else clause, gradually eliminating each possible error condition. This style of programming was later termed in the Go community "Aligning the happy path to the left"[1][2] [1] https://medium.com/@matryer/line-of-sight-in-code-186dd7cdea88 https://medium.com/@matryer/line-of-sight-in-code-186dd7cdea... [2] https://maelvls.dev/go-happy-line-of-sight/ https://maelvls.dev/go-happy-line-of-sight/ I wholeheartedly agree that this style makes code more readable and I have adopted it - and encouraged others to adopt it - in other languages besides Go. This style would stil be followed with the try or check/handle proposals. For instance, let's take the example: f, err := os.Open(name) if err != nil { return err } d, err := f.Stat() if err != nil { f.Close() return err } codeUsing(f, d) f.Close() return nil With the simple try proposal that would be: f := try(os.Open(name)) defer f.Close() d := try(f.Stat()) codeUsing(f, d) With OP's variant of the try proposal, using a question mark this is arguably even more readable (less noisy): f := os.Open(name)? defer f.Close() d := f.Stat()? codeUsing(f, d) As you can see, these proposal reduce - not increase - nesting, so they are completely in line with what Effective Go is saying.
  - sagichmal 5y ago
    You continue to assert that error handling adds noise to a block of code. This is an opinion, that's fine, but it's not an objective truth. In many many domains -- in fact the domains which Go targets -- error handling is equally important to business logic.
sagichmal 5y ago
That is not at all what those links indicate.