proposal: Go 2: errors: allow function on left hand side of assignment

[switchupcb]

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
#52416 (comment)
#52416 (comment)
#52416 (comment)
#52416 (comment)

Potential Supporters

@ianlancetaylor Due to my flow control.
@networkimprov he did it. he solved go errors.

Similar Proposals (Not Duplicates)
#21732 @faiface +8 -8
idek @lldld
#14066 @gertcuykens
#46655 @smasher164

Symbolic Proposals
#50207 @misaka123456
#42214 @kidlj
#32884 @integrii @alanfo
#42318 @be-impl +18 -19 @sirkon
#36390 @cmidt-veasna -5

Implications: #52415
More Implications: #52380

Downvote Offset: #52416 (comment)

[ianlancetaylor]

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.

In this example:

    ballin, fmt.Errorf("error: balled too hard\n%w", err) := isBaller(bucko + bucks, 2147483647)

where is err declared?

This seems pretty similar to #32473.

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?

[switchupcb]

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.

[switchupcb]

@efronlicht I have a broken keyboard right now so I can't use bigger words.

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

[switchupcb]

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

WHAT HAPPENS HERE MR SMART GUY? HUH! IS a RETURNED AS WELL?

[switchupcb]

What happens in any other case.

// in a func that returns string and error
if err != nil {
   return "", err
}

Your question is not an issue with any proposal but rather the way Go handles values. Are other values reliable or not when an error is returned? _ implies that they can be. However, when that is the case, you have ignored the error explicitly (with _), implying that the other value is useful.

The difference here is that we are not USING variables but returning them. The reason you use the zero value for everything other than error is because we can't assume that the func wrap returns the result. As an example:

func leet() (string, error) {
     // a is a bool, not a string
     // err is an error, which fmt.Errorf returns
    fmt.Errof("%v, %w", a, err) := simple() // return "", err when err != nil

    return "code", nil
}

There is one significant drawback to [the current] approach, at least for some applications: there is no way to know how much of the processing completed before the error occurred. If that information is important, a more fine-grained approach is necessary. Often, though, an all-or-nothing check at the end is sufficient.
— @robpike

To be honest, keeping errors the same isn't that bad. Google has like 20000 programmers so 3 lines shouldn't be a big deal. Google can adopt trio-programming or require more leetcode during interview. The industry will catch on eventually.

EDIT: panic and recover can be used on all values making it consistent. So the question becomes whether we limit assignment funcs to a single error and returning zero values for everything else.

[switchupcb]

@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

[sirkon]

Stop mention me please.

This proposal is all about LOC reduction at the cost of line width and readability. I don't see how it solves real issues of Go error handling, some of the are:

1. No type system support for mandatory error handling. I mean you can write like this and will get NPD in the end:

    file, err := os.Open(filename)
    if err != nil {
        fmt.Println(err)
    }
   
    filedata, err := io.ReadAll(file)
    …
   

2. Some kind of "instability" of error handling:

    if err := f(x); err != nil {
        …
    }
   

And this fragment must be rewritten completely if a new return parameter is added:

     res, err := f(x)
     if err != nil {
         …
     }

Back to your proposal:

• It doesn't solve No 1
• It will make kind of rewrites of No 2 straightforward in simplest cases where it just returns raw or wrapped error. In the same time it will introduce a more annoying kind of literal "instability" where you need to extend error processing logic.