"  It does seem that a lot of key decisions are being made on the basis of 
a very small sample of emoji votes in the issue tracker, so having a 
broader voting mechanism might be useful for informing the decision making 
process.. .."

At the very least, 'a broad voting mechanism'  would eliminate tons of 
repetitive posts regarding issues like ' if err != nil {..} '  and help Go 
developers focus of issues of major importance to Go users   

On Sunday, June 14, 2020 at 9:50:27 PM UTC-4, Randall O'Reilly wrote:
>
> I noticed a kind of circularity in the arguments around this issue.  The 
> simple "inline the if block" issue was created and rejected earlier: 
> https://github.com/golang/go/issues/27135 -- in part because the central 
> issue of error handling logic was supposed to be resolved by some other 
> upcoming proposals.  The newer issue: https://golang.org/issue/38151 has 
> some additional elements that potentially detract from the basic gofmt-only 
> version, and it has also been closed.  There is also this closely related 
> proposal which has not yet been rejected: 
> https://github.com/golang/go/issues/37141 
>
> Overall there is certainly a consistent message from a substantial number 
> of people that just compressing that high-frequency `if err != nil` logic 
> down to 1 line *somehow* would solve most of the problem!  But then there 
> are those who argue in favor of the status quo. 
>
> Because consistency in formatting is an essential part of Go, it seems 
> that this is fundamentally an "aesthetic" decision that must either be made 
> by the core designers, or, perhaps, finding some way of performing a 
> large-scale democratic voting process that would reasonably enable a large 
> portion of the Go community to weigh in.  It does seem that a lot of key 
> decisions are being made on the basis of a very small sample of emoji votes 
> in the issue tracker, so having a broader voting mechanism might be useful 
> for informing the decision making process..  Anyone know how to write a 
> good vote-collecting webserver in Go? :) 
>
> - Randy 
>
> > On Jun 14, 2020, at 12:39 PM, Tom Limoncelli <t...@whatexit.org 
> <javascript:>> wrote: 
> > 
> > Great minds think alike! 
> > 
> > On Sun, Jun 14, 2020 at 12:56 PM Ian Lance Taylor <ia...@golang.org 
> <javascript:>> wrote: 
> >> 
> >> On Sun, Jun 14, 2020 at 8:25 AM Tom Limoncelli <t...@whatexit.org 
> <javascript:>> wrote: 
> >>> 
> >>> On Thu, Jun 4, 2020 at 3:34 PM Ian Lance Taylor <ia...@golang.org 
> <javascript:>> wrote: 
> >>>> 
> >>>> On Thu, Jun 4, 2020 at 8:43 AM <lgo...@gmail.com <javascript:>> 
> wrote: 
> >>>>> 
> >>>>> ?? Why not a cleaner syntax e.g.  x = some_func ()  #{ }   .. symbol 
> # arbitrarily chosen 
> >>>> 
> >>>> Besides what other people have said, it may be of interest to glance 
> >>>> through 
> https://github.com/golang/go/issues?q=is%3Aissue+label%3Aerror-handling 
> >>> 
> >>> I assert that 80% of the annoyance that people feel is the number of 
> >>> lines required to handle errors, not the syntax.  Thus, a large 
> >>> segment of the community would stop caring about this if we modified 
> >>> gofmt, not the go language.  Specifically, gofmt would simply format 
> >>> short if's on one lie when possible. 
> >>> 
> >>> OLD: 
> >>> 
> >>> a, err := ioutil.ReadFile(patha) 
> >>> if err != nil { 
> >>>      return err 
> >>> } 
> >>> b, err := ioutil.ReadFile(pathb) 
> >>> if err != nil { 
> >>>      return err 
> >>> } 
> >>> c, err := ioutil.ReadFile(pathc) 
> >>> if err != nil { 
> >>>      return fmt.Errorf("wrapped %v: %w", pathc, err) 
> >>> } 
> >>> 
> >>> NEW: 
> >>> 
> >>>  a, err := ioutil.ReadFile(patha) 
> >>>  if err != nil { return err } 
> >>>  b, err := ioutil.ReadFile(pathb) 
> >>>  if err != nil { return err } 
> >>>  c, err := ioutil.ReadFile(pathc) 
> >>>  if err != nil { return fmt.Errorf("wrapped %v: %w", pathc, err) } 
> >>> 
> >>> This is half as many lines, thus makes it easier to fit on one 
> >>> screenful of an editor, which is often a cognitive limit for a 
> >>> developer. 
> >>> 
> >>> I'm not saying that this solves the problem, but I bet it would reduce 
> >>> the pressure to fix it. 
> >> 
> >> 
> >> 
> >> https://golang.org/issue/38151 
> >> 
> >> Ian 
> > 
> > 
> > 
> > -- 
> > Email: t...@whatexit.org <javascript:>    Work: 
> tlimonce...@stackoverflow.com 
> > Blog:  http://EverythingSysadmin.com/ 
> > 
> > -- 
> > 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 golan...@googlegroups.com <javascript:>. 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CAHVFxgmaFQoRaZd65FLbzZUWD4bKFqaWcqXQ3H7vm%3DNimi6B2g%40mail.gmail.com.
>  
>
>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/14f904c8-bfa1-4f9f-afe6-c099ee2da575o%40googlegroups.com.

Reply via email to