proposal: Go 2: Error-Handling Paradigm with !err Grammar Sugar

[shynome]

Hi, if you like this idea please give a heart emoji to me, Thank you very much

//  before, 4 line
f, err := os.Open()
if err != nil {
  return
}

// now, 1 line
f, !err := os.Open()

I plan to impl this by gone-lang, your like emoji can speed development

[ianlancetaylor]

Similar to #25273, #32500, #32884, #33074, #33150. See also #40432.

[shynome]

I think my proposal has the least broken

[seankhliao]

Duplicate of #14066

[shynome]

@seankhliao I don't know why you just because of they looks similar then close this, this has diffrence, this issue add limit for sugar so it easy to implement

[ianlancetaylor]

We have rejected many issues that are very similar, if not identical, to this one. Just as those were not accepted, we aren't going to accept this one. As I mentioned, please see #40432. Sorry.

[shynome]

so much proposal, can we make an vote to known which proposal is much popular? I really hate go error handle, so much template code

[ianlancetaylor]

Sorry, we don't make changes to the Go language on the basis of voting.

We are aware that error handling boilerplate is a concern. There have been many, many, proposals to address it. There has been an enormous amount of discussion on the topic.

[shynome]

here is my try: https://github.com/shynome/err4 .implement this by use code generate.

I'm so sorry for what I said. I didn't mean to hurt your feelings.

[ianlancetaylor]

No worries.

[shynome]

https://github.com/golang/go/issues/14066#issuecomment-173779313

I think the Proposal-Decline reason does not apply now, This year is 2023 not 2016, this year we have got generic type, a change bigger than this proposal, golang team can consider this again

[ianlancetaylor]

We've identified many similar issues. They have all been closed. This isn't an approach we are likely to take with Go. Sorry.