go: proposal: Go 2: errors: allow function on left hand side of assignment
Backwards compatibility should be a function of a previous design’s quality. It should NOT be a function of adherence to backwards compatibility. Go 2 does not promise to be compatible with Go 1: While compatibility is nice to have, it isn’t required. Change is inevitable. So why are we limiting ourselves on this specific issue? Luckily, the answer to that question does NOT matter for this proposal. It’s backwards compatible and boomer approved.
With that out of the way…
Proposal
You want error handling ideas. Yet restriction is bad for creativity. This proposal is unhinged. I might not even like it… but I’m making it anyways. Perhaps, my outlook will change. Perhaps it won’t and I will regret this decision for the rest of my life. All I know is that it isn’t a duplicate.
An error is a value in Go, so anything that is applicable to errors should also be applicable to values; except panic and recover I guess… If we are going to use a function, it is either a built-in or keyword; none of this top of the page, 4th dimension, quantum realm nonsense.
People want to be able to return if not nil, wrap errors, and feed their families, all with a single error feature. Now, I’m not gonna lie: This one might leave lil timmy a lil hungry. Expecting a single feature to handle errors is like expecting the language to work without if statements and… Let’s not get ahead of ourselves here. This proposal will meet the requirements.
At this point, I know you have your tongue out panting like a dog in front of your computer. heh heh heh. Otherwise, you are NOT amused right now. You may be asking yourself if this post even has a proposal in the first place. It does. I just needed to make it longer so it seems more sophisticated than the other ones. So without further ado…
Add the ability to accept functions in place of a value - or only error values - if it isn’t equivalent to its zero value.
func bezo(baller, dollers string) error {
bucko, (err) := strconv.Atoi(baller) // returns err if not nil
bucks, _ := strconv.Atoi(dollers)
fmt.Println("$:", bucko + bucks)
ballin, fmt.Errorf("error: balled too hard\n%w", err) := isBaller(bucko + bucks, 2147483647) // returns err if not nil
if ballin {
take50(err) := MakeMackenzieHappy() // returns err (cause not nil)
}
return nil
}
For the MENSA members out there.
func musk(money string) (bool, error) {
if money == "long" {
money = "longer"
}
sec, fmt.Tweet(err) := findSEC() // returns false, fmt.Tweet(err) error if not nil
RunFrom(sec)
return false, nil
}
READ THE FOLLOWING FOR CONTEXT BEFORE COMMENTING https://github.com/golang/go/issues/52416#issuecomment-1102798612 https://github.com/golang/go/issues/52416#issuecomment-1103143640 https://github.com/golang/go/issues/52416#issuecomment-1103242932 https://github.com/golang/go/issues/52416#issuecomment-1103258279
Potential Supporters
@ianlancetaylor Due to my flow control. @networkimprov he did it. he solved go errors.
Similar Proposals (Not Duplicates) https://github.com/golang/go/issues/21732 @faiface +8 -8 idek @lldld https://github.com/golang/go/issues/14066 @gertcuykens https://github.com/golang/go/issues/46655 @smasher164
Symbolic Proposals https://github.com/golang/go/issues/50207 @misaka123456 https://github.com/golang/go/issues/42214 @kidlj https://github.com/golang/go/issues/32884 @integrii @alanfo https://github.com/golang/go/issues/42318 @be-impl +18 -19 @sirkon https://github.com/golang/go/issues/36390 @cmidt-veasna -5
Implications: https://github.com/golang/go/issues/52415 More Implications: https://github.com/golang/go/issues/52380
Downvote Offset: https://github.com/golang/go/issues/52416#issuecomment-1101794012
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 77
- Comments: 27 (4 by maintainers)
I don’t understand why this has so much weird meme-ish language. It makes it difficult for me to follow what you are talking about. Can you please cut out the noise and restate your proposal as simply as possible?
@efronlicht I have a broken keyboard right now so I can’t use bigger words.
@efronlicht @smasher164 @Solumn @kidlj @sirkon @l-zeuch @jimen0 @generikvault @zxr90 I used big words.
Is this some kind of bizarre performance art? I’ll leave you to it.
WHAT HAPPENS HERE MR SMART GUY? HUH! IS
aRETURNED AS WELL?@sirkon Well, if it’s an issue from 58% of Gophers, we need to make proposals on it. I think you bring up yet another possible idea: remove a method of handling errors to standardize the language entirely. This isn’t backwards compatible but it may have benefits that outweigh the current way of doing things.
I just want to note that this is not true of Go today, and making it work that way would be an incompatible change. Code can call
panicwith a value of any type, and recover will return whatever value is passed topanic.@switchupcb Please follow the Go Community Code of Conduct. Please be polite and respectful in your comments on this issue tracker.
@switchupcb I’m not disputing any of that, nor making any statement on the proposal; just clarifying.
@ianlancetaylor You explained it! The #32473 is similar but his example is a bit complicated. It shouldn’t be much more complicated than what you said. Also, we should NOT allow keywords such as
return,breakon the LHS.Th
erris declared in the function on LHS.Based on the discussion above, and the emoji voting, this is a likely decline.
Leaving open for four weeks for final comments.
dispite whatever it is, go team should put a better error handle on the agenda, people bored to write more if err != nil. may be you can take a look https://github.com/goplus/gop/wiki/Error-Handling . after all, they already implemented a better error handle way.