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)

Most upvoted comments

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.

alt-73 alt-32 alt-117 alt-115 alt-101 alt-100 alt-32 alt-98 alt-105 alt-103 alt-32 alt-119 alt-111 alt-114 alt-100 alt-115

Is this some kind of bizarre performance art? I’ll leave you to it.

fmt.Errof("%v, %w", a, err) := simple()

WHAT HAPPENS HERE MR SMART GUY? HUH! IS a RETURNED 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.

This is an implicit statement: panic and recover can only be used on error values.

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 panic with a value of any type, and recover will return whatever value is passed to panic.

@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.

If I’m following this, you are suggesting that we permit functions on the left hand side of an assignment. If we assign a non-nil value to a function, then we instead call the function, and then we return the result of calling the function from the caller.

@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, break on the LHS.

Th err is 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.