proposal: Go 2: errors: return if

[switchupcb]

Amazing news. I no longer have a broken keyboard.

In celebration, I've made yet another error proposal.

Fundamentals

Contrary to popular belief, using words that make you sound smart isn't what makes a good error proposal. It's having fundamentals. Those aren't defined by silly language concepts, but by looking at the code. panic, recover, _ are mostly used to handle errors, but they can also handle non-errors too. That's because errors are values. Don't be an exception, be like Rob Pike.

In short, a valid errors srorre' proposal is one that follows these rules.

Proposal

The Form

Would you consider yourself a novice, intermediate, or experienced Go programmer? What other languages do you have experience with?
https://switchupcb.com/projects

Has this idea, or one like it, been proposed before?
I couldn't find a return if using search nor @seankhliao's website.

Is this change backward compatible? Does this affect error handling?

The Explanation

So the issue with proposals like #37141 and #52416 is that they focus too much on the errors. We go on and on about technical nonsense, only to end up with: "This proposal would be good if it was limited to errors." Once you hear those words, it's time to buy the casket. Some people want new keywords, some people don't. Others are if err != nil maxis, but they have a point: Why add a new mechanism for errors when it was right in front of us the whole time?

You could take pass and rename it to rinn (return if not nil), allow it to be used on values and functions, then call it a day. Or... we could just figure out how to make using the if statement better?

JavaScript and Ruby have return if. Other languages have ternaries. We are not the same.

The Code

func bezo(baller, dollers string) error {
    bucko, err := strconv.Atoi(baller)
    return if err != nil { err }
    bucks, _ := strconv.Atoi(dollers)
    fmt.Println("$:", bucko + bucks)

    ballin, err := isBaller(bucko + bucks, 2147483647)
    return if err != nil { fmt.Errorf("error: balled too hard\n%w", err) }
    if ballin {
        err := MakeMackenzieHappy()
        return if err != nil { err }
    }
    return nil
}

Alternative Implementation

func bezo(baller, dollers string) error {
    bucko, err := strconv.Atoi(baller)
    return err if err != nil
    bucks, _ := strconv.Atoi(dollers)
    fmt.Println("$:", bucko + bucks)
    ...

Alternatively

func bezo(baller, dollers string) error {
    bucko, err := strconv.Atoi(baller)
    if err != nil { return err } // allow one-line
    bucks, _ := strconv.Atoi(dollers)
    fmt.Println("$:", bucko + bucks)
    ...

The Theme Song

I will travel across the land, searching far and wide.
To teach Go devs to understand, the power that's inside.
(Go Errors, Gotta Catch Em All) It's you and me
I know it's my destiny
(Go Errors) Oh, you're my best friend
In programs we must defend
(Go Errors, Gotta Catch Em All) If err not nil
A return will pull us through
You teach me and I'll teach you
Go Errors! (Gotta Catch 'em all) Gotta Catch 'em all (Go Errors!)

Testimonials

I love using if statements on a nice summer evening. Using them with return would be even better!
— @sirkon

Security consultant here.

The fact that Golang has no return if is a huge thing. I've read countless amount of code that abused return if statements (unfortunately developers think they have to use return if all the time if they are available) and is probably completely insecure for the simple reason that very few people manage to audit/understand the code. If return if could only be used when necessary, yes, but there are no technical ways to enforce this.

What I'm saying is that in my years of security consulting, Golang codebases have always been the clearest ones to read and have always been the most secure ones. I feel like a lot of the negative perspectives are given from the writing point of view, but the reading perspective is clearly a huge win for Golang.
— Security Consultant

Voting

Democracy basically means... government... by the people... of the people... for the people... but the people are... r ust zealots?? macros??? The only macros I want are macronutrients from Go Cereal on a summer morning.

Look. If you have to use 15000 majillion gigabillion technical terms to describe your error proposal, you messed up. I know how a lot of you are. You have some idea in your head so you downvote everyone else's without thinking. That's the problem. It's not your idea. Yet no one will remember these posts. No one will remember who solved Go errors. As long as you are concerned, your idea is ours.

Thanks :D

Now go submit your idea because we need more ideas. Go is the source of the next web revolution.

To the inevitable person who is supposed to be all serious and logical, but then cries about the delivery of this post: You are not special. We get paid to press buttons. It's really not that complicated.

[switchupcb]

Potential Supporters: @hummerd, @jdmaguire, @griggsca91, @SealOfTime, @dfreilich, @mccolljr, @komuw, @gweithio, @rw-access, @kalverra, @Splizard, @elnardu, @schrej, @schwrzstrbn, @4ad, @efronlicht, @pierrec, @codemicro, @pacuna, @Drache93, @oz, @maja42

Shoutout: @ianlancetaylor (mega baller alert)

and maybe @griesemer when asts can handle comment manipulation.

[codemicro]

Please don't mention me out of nowhere.

[jdmaguire]

I have no idea what this proposal is for but I love it nonetheless.

[mccolljr]

You're not the first person to make a similar proposal, and the others have not been accepted.

IMO this doesn't save enough typing to justify a language change.

I could support gofmt supporting one-line block expressions though, it would let me take up less vertical space on my screen for long chains of error handling

[SealOfTime]

I don't understand, why I have been mentioned, but nonetheless I wouldn't support this proposal at this stage.

To begin with at this moment this proposal is lacking example of code for function with multiple return values.

Moreover, this proposal suggests a syntactic synonym of existing and wide-spread go idiom

if err != nil {
    return fmt.Errorf("wrapped: %w", err)
}

Alternatively, it just suggests adding another way to write this down to be allowed in go fmt.

In my opinion, this would only decrease the code readability by introducing another way to do just one thing, which from my experience leads to incoherent codebase. Additionally, this way to writing down error delegation discourages giving handled errors context.

[seankhliao]

Single line if ... { } is #33113 #27135
This looks like #27794 #32860 with the order switched
Closing as dup

[mvdan]

And, as Ian already mentioned before, please follow the code of conduct. The majority of your post is completely unrelated to the proposal at hand, the overall tone is distracting, and you're pinging two dozen people at once - none of which are a good start for a productive proposal discussion.