Seems slightly unfortunate that we always have to call the errors.Wrap function even when there is no error.

For language change proposals, please fill out the template at https://go.googlesource.com/proposal/+/refs/heads/master/go2-language-changes.md .

When you are done, please reply to the issue with @gopherbot please remove label WaitingForInfo.

Thanks!

@gopherbot please remove label WaitingForInfo

The idea would be that as soon as err is non-nil, it's automatically returned.
This could probably be leveraged by more than just errors.
That being said, (err error pass) feels awfully long - but in my opinion, it would definitely be an improvement over having to type pass err at every step of the way.

Just my 2 cents

My concern is that it would make it less explicit and maybe a little more difficult to understand.
Calling pass is still easy. Imagine having a function with multiple return values. pass will make it much simpler anyway.

Also, Go allows separating statements with semicolons so you can technically do it in one line but not sure if it is something that would be preferred.

n, err := f.Write(data) ; pass err

if n < len(data) {
 return io.ErrShortWrite
}
return f.Close()

Why not go one step further and do something like:

result, pass err := someFunc()

Your version of WriteFile is wrong. While the original function will always close the file, your version will return if there is an error in f.Write or n<len(data) without closing the file. You could use defer, but then you will miss the error returned by f.Close. At the end, I think you would only be able to replace thee first return, so this may not be the most compelling example.

@yiyus good catch! I updated the example to show something a bit more involved, and when pass can realistically be used.

It seems that pass v requires v to have type error and is shorthand for

    if v != nil {
        return ..., v // here ... is the zero value for the other result parameters
    }

It's unfortunate that error wrapping requires calling the function even when the error is nil, but on the other hand it would not be too hard for the compiler to check whether the wrapper function starts with

    if err == nil {
        return nil
    }

and pull those lines into caller without inlining the whole function.

The name pass is certainly used as a variable name in existing code (e.g., https://golang.org/src/crypto/sha512/sha512_test.go#L664), and that code would break.

Also the name pass doesn't seem to really describe the operation here. The word "pass" often means to pass over something, but in this case we are--passing it up to the caller? Passing over the rest of the function? I'm not sure.

One possibility would be to use return? or return if instead of pass.

    return? err
    return if err

As you know, there has been a lot of discussion about error handling in Go. Is this language change big enough for the problem? It saves about six tokens and two lines. Is that worth the cost of a language change?

I really like the return if err version of this idea: it directly summarizes the three lines of code that it replaces, and doesn't introduce any new keywords, logic or anything else other than addressing the one consistent sore point with the existing situation: it takes a lot of space and eyeball friction for such a high-frequency expression. Also, I've definitely mistyped err == nil instead of err != nil several times without noticing, so avoiding the need for that is a bonus.

You've already tried to change the language to fix this problem, so it seems that there is a general agreement that it is worth fixing, and this is just about as minimal, yet impactful, a change as could be made. If it survives the flamethrowers, it would probably build a good feeling in the community that there really is a willingness to fix the few existing sore points in the language..

The other possibility we could shorten with guard keyword because in most case if err != nil can be error prone for fast typing and @rcoreilly have the same issue. With guard provides less typing and encourage developers to handle the "error" instead of verifying if the error is not nil.

Return error (type errors) if not nil:
guard err

Return true (boolean) if the error match:
guard err == “code”

To return custom error (multiple variables):

guard err {
    return nil, err
}

The name pass is certainly used as a variable name in existing code (e.g., https://golang.org/src/crypto/sha512/sha512_test.go#L664), and that code would break.

It should be trivial for a simple tool to fix these usages (maybe go fix can deal with that?). It is reasonable to assume that for a new major version, you need to at least run a small command to make your code compatible.

Also the name pass doesn't seem to really describe the operation here. The word "pass" often means to pass over something, but in this case we are--passing it up to the caller? Passing over the rest of the function? I'm not sure.

One possibility would be to use return? or return if instead of pass.

    return? err
    return if err

pass means passing the error up to the caller. If you think about it, it is slightly similar to throw in other languages but more polite because it deals with error values instead of exceptions.

return if and return? are also worth considering. But I think another usage of pass will naturally lend itself at least because it is possible.

Instead of filling zero values for the result parameters, it is possible to do this:

func someFunc() (int, int, error) {
    if n > N {
        return? errors.New("n cannot be greater than N") 
    }
    
    ...  

In this case, pass may sound slightly better.

func someFunc() (int, int, error) {
    if n > N {
        pass errors.New("n cannot be greater than N") 
    }

    ...  

Normal usage:

func someFunc() (int, int, error) {
    if n > N {
        return 0, 0, errors.New("n cannot be greater than N") 
    }

    ...  

but I think I like return? mostly because pass may overlap with return in some cases.

As you know, there has been a lot of discussion about error handling in Go. Is this language change big enough for the problem? It saves about six tokens and two lines. Is that worth the cost of a language change?

If developers only had to write if err != nil { ... } once then, it may not be worth it, but if that was the case there wouldn't be many error handling proposals to begin with. Six tokens and two lines add up. It is not ergonomic.

This proposal should fix the most common case. If you want to handle the error (not pass it), i like the current method. Errors are values, you can check for it with an if statement and do something. Adding something like check and handle may make the code only slightly cleaner in some cases but can also add more complexity.

This example looks pretty good as well if you prefer return? instead of pass:
It is also a good representation of the harder cases.

func CopyFile(src, dst string) error {
	r, err := os.Open(src)
	return? fmt.Errorcf(err, "copy %s %s: %v", src, dst, err)
	defer r.Close()

	w, err := os.Create(dst)
	return? fmt.Errorcf(err, "copy %s %s: %v", src, dst, err)

	if _, err := io.Copy(w, r); err != nil {
		w.Close()
		os.Remove(dst)
		return fmt.Errorf("copy %s %s: %v", src, dst, err)
	}

	if err := w.Close(); err != nil {
		os.Remove(dst)
		return fmt.Errorf("copy %s %s: %v", src, dst, err)
	}
	return nil	
}

It is much more ergonomic in my opinion than the current way (btw the example above takes only one extra line compared to check and handle example https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md).

It is reasonable to assume that for a new major version, you need to at least run a small command to make your code compatible.

We can certainly do this if we must. But it's a cost. We shouldn't just ignore that cost.

pass means passing the error up to the caller.

I guess. That doesn't seem like a natural meaning of "pass" to me, though. The first meaning that jumps to mind for me is to pass over something, meaning to ignore it. Any other opinions on this point?

I don't dispute that pass is more ergonomic. The thing is, we only get to change this once. We can't iterate on error handling. Is this improvement ergonomic enough?

I see now that a problem with return? or return if is that they would only list a single result, whereas the normal return statement of course lists all results (or none, if the results are named).

pass means passing the error up to the caller.

I guess. That doesn't seem like a natural meaning of "pass" to me, though. The first meaning that jumps to mind for me is to pass over something, meaning to ignore it. Any other opinions on this point?

it is returning the error up to the caller, and given that we already have a keyword that means return it seems like it makes sense to use that, right?

Given that the language already has two forms of return logic (named vs. unnamed), adding a third seems reasonable. The named form already does some "magic" by not directly listing the values returned. This proposed form just adds an additional, logical case that says if you're returning without achieving the mission of the function, return zero values.

return? maybe seems too "ternary" for the Go language? return if seems like a natural way to say "conditional return" using the existing language elements..

I don't dispute that pass is more ergonomic. The thing is, we only get to change this once. We can't iterate on error handling. Is this improvement ergonomic enough?

What I like about Go is that it often picks the simplest approach to solve a problem. The proposed change is consistent with that. It is a minimal change, but very impactful. It is ergonomic. It reduces boilerplate code and helps you focus on the critical parts of a function.

If you choose to go with return? or return if instead of pass, "conditional return" does sound like a good name for it. For me return? looks nicer than return if after trying it in some examples.

Seems slightly unfortunate that we always have to call the errors.Wrap function even when there is no error.

This is a concern, especially for uses of fmt.Errorf() with %w. If a lot of errors in a function need wrapping, that's a lot of pointless overhead to parse the formatting string, run stuff through reflection, and allocate new stuff just to throw it away 90% of the time.

Maybe as an alternative, an optional second argument could be given and, if it is, than the the first argument is only used for the nil check. For example,

// If err is not nil, execute and return the second argument.
return? err, fmt.Errorf("some extra information: %w", err)

// Alternative: Do a simple boolean check on the first argument. That
// makes this more cleanly just shorthand for an if statement.
return? err != nil, fmt.Errorf("some extra information: %w", err)

The downside to this, though, is that with just a ? to differentiate, this could be a bit awkward to read at a glance. The alternative above in particular might work better with the return if syntax instead.

Edit: This is assuming that fmt.Errorf() returned nil if the %w target is nil, which I don't think that it does at the moment.

@DeedleFake I didn't use fmt.Errorf() in the example with return?. I used fmt.Errorcf() which takes an error as the first argument to check for nil. This function doesn't actually exist but it is just an example.

The more I think about it, the more I like the way errors are currently handled in Go.

IMO, return? sounds great in theory, but in practice, I have a feeling it'll make reading the code harder.

Not just that, but ignoring other use cases, for error handling, all this is doing is removing the need for writing if err != nil { and }.

Let's say that this is sufficient in term of error handling and we decide to go with return? or return if, then we're met with the fact that since we're using something as generic as the keyword return, return? will need to support returning multiple values - not just one.

To do that, return? would need to have an extra argument - a condition, which like I said earlier, will most likely make the code harder to read.

Unlike what @DeedleFake mentioned, I don't think the default behavior should be checking if the first argument is nil, because if return? is to work with values other than error, then what happens with values that cannot be nil (i.e. string)?

This leaves us with the following:

something, err := getSomething()
return? err != nil, nil, err 
return something, nil

I think that this is a downgrade from the existing:

something, err := getSomething()
if err != nil {
    return nil, err 
}
return something, nil

Even though there's more LoC, at least there's no confusion, and the number of returned values match with the function signature.

Also, the examples used for the return? condition all have a conveniently small conditions, but take something like this as example:

func ValidatePassword(password string) (bool, error) {
	if len(password) < MinPasswordLength {
		return false, fmt.Errorf("password must have at least %d characters", MinPasswordLength)
	}
	if len(password) > MaxPasswordLength {
		return false, fmt.Errorf("password must have less than %d characters", MaxPasswordLength)
	}
	return true, nil
}

With return?, we'd have this instead:

func ValidatePassword(password string) (ok bool, err error) {
	return? len(password) < MinPasswordLength, false, fmt.Errorf("password must have at least %d characters", MinPasswordLength)
	return? len(password) > MaxPasswordLength, false, fmt.Errorf("password must have less than %d characters", MaxPasswordLength)
	return true, nil
}

It looks nice, but the lines are quite a bit longer - and there's just two values being returned.

Personally, with named parameters, it'd look even better:

func ValidatePassword(password string) (ok bool, err error) {
	if len(password) < MinPasswordLength {
		err = fmt.Errorf("password must have at least %d characters", MinPasswordLength)
	} else if len(password) > MaxPasswordLength {
		err = fmt.Errorf("password must have less than %d characters", MaxPasswordLength)
	} else {
		ok = true
	}
	return
}

But I digress.

That said, I think the suggestion for pass has its merits, but more importantly, it's targeted at error handling, whereas return? has a wider implications that also happens to be something that can be leveraged for error handling.

As @ianlancetaylor mentioned, I also think that the word pass might be inappropriate for this use case. pass does not convey "pass this value to the caller if the value passed is not nil". assert or check would make more sense for me, but even these two don't feel explicit enough to me.

@TwinProduction if return? is preferred instead of pass. Even if we wanted to support optionally adding return values for return?. It should still match the result parameters. There is no need for an additional condition, and it will still work the same way.

func someFunc() (int, error) {
    f, err := os.Open(filename)
    return? 0, err
   
    // do other things

the conditional return will only check if the error value != nil (the proposal already specifies that the error type must be the last result parameter)

I haven't seen anybody try to address this point:

It saves about six tokens and two lines. Is that worth the cost of a language change?

As far as the keyword goes, what about check?

One of the arguments against the try proposal (#32437) was that it introduced another kind of flow of control. This same consideration arises with this proposal.

It's a little odd that in an expression like

    pass errors.Wrap(err, "x")

the reader has to understand that errors.Wrap will always be called, but that the pass (or whatever) is basically keyed on whether the original err value is nil (but expressed as whether errors.Wrap returns nil). This is definitely doable, but is it confusing? Especially to people new to Go?

@ianlancetaylor since it's a keyword, can't we make it lazy evaluate the call?

func xyz() (int, err) {
	x, err := fn()
	pass errors.Wrap(err, "xyz")
	
	if x != 0{
		return x * x * x, nil
	}

	return 1, nil
}

// would be the same as:

func xyz() (int, err) {
	x, err := fn()
	if err != nil {
		return 0, errors.Wrap(err, "xyz")
	}

	if x != 0{
		return x * x * x, nil
	}

	return 1, nil
}

It saves about six tokens and two lines. Is that worth the cost of a language change?

As an experienced developer reading a function I am not familiar with, I commonly skim down the page looking at its control flow structure. I look for loops, branches, and return points to get a high level idea of the type of function I am looking at. To identify the return points I currently only need to look for two words, "return" and "panic". The first is ubiquitous and the second is rare, which means in a practical sense I can quickly scan for lines starting with the word "return."

The proposed keyword "pass" introduces a new word to look for that would also be ubiquitous. I believe that is a considerable cost. The alternatives of "return if" or "return?" do not incur that cost.

I don't know how to pronounce "return?" in my mind or when reading code to a colleague, and adding a keyword that contains a non-alpha character is stylistically out of step with the rest of the language.

"return if" seems more natural to me. It has a clear pronunciation when reading and is reminiscent of the "else if" clause already present in the language. But "return if" has the cost that, unlike "if" or "else if", it takes an error expression instead of a boolean expression. But that cost seems lower than the costs of "pass" or "return?" to me.

Is the cost of adding "return if" worth it to save two lines and maybe some explicit zero values? Maybe. I am generally skeptical of the argument that the repetition of if err != nil { return ... } is a large burden to reading Go code. But this proposal has perhaps the best value/cost ratio we've seen so far.

How about simply using return to pass errors:

func someFunc() (int, error) {
    f, return := os.Open(filename)

return replaces if err!=nil {return ...,err}, without an explicit declaration of err variable. If you need to wrap the error, handle it, or print, log, etc. you would still use the current error handling boilerplate.

@bserdar That suggestion is quite similar to #32500, #32601, #32884, and perhaps others. Let's not discuss that suggestion in this issue. Thanks.

Been thinking about this over the weekend and I was initially attracted to the idea but as I have processed the comments the idea of magically inlining parts of a wrapped function or eating the penalty of value creation and throwing it away feel untenable.

But there's clearly a problem that needs to be solved otherwise we wouldn't be banging our heads against it ad infinitum.

@bserdar's comment doesn't seem too off base in the service of trying to find a solution even if it is not direct feedback on the solution at hand.

But the overloading of return is a non-starter for me and after reviewing the linked issues, they are all just kinda awkward syntax wise (!! and ? don't read naturally to my eye). I have been playing with the idea of using a caret (^) as a sentinel value very similar to the underscore (_) to eliminate much of the boilerplate without buying new keywords and flow control or overloading semantics. My thinking is that the underscore means "table the value" and the caret means "send the value back up".

Looking at xbit's example in the proposal, here is an equivalent with less trade-offs and language impact...

before:

func newGitRepo(remote string, localOK bool) (Repo, error) {
	r := &gitRepo{remote: remote}
	if strings.Contains(remote, "://") {
		var err error
		r.dir, r.mu.Path, err = WorkDir(gitWorkDirType, r.remote)
		if err != nil {
			return nil, err
		}

		unlock, err := r.mu.Lock()
		if err != nil {
			return nil, err
		}
		defer unlock()

		if _, err := os.Stat(filepath.Join(r.dir, "objects")); err != nil {
			if _, err := Run(r.dir, "git", "init", "--bare"); err != nil {
				os.RemoveAll(r.dir)
				return nil, err
			}
	
			if _, err := Run(r.dir, "git", "remote", "add", "origin", "--", r.remote); err != nil {
				os.RemoveAll(r.dir)
				return nil, err
			}
		}
		r.remoteURL = r.remote
		r.remote = "origin"
	} else {
		if strings.Contains(remote, ":") {
			return nil, fmt.Errorf("git remote cannot use host:path syntax")
		}
		if !localOK {
			return nil, fmt.Errorf("git remote must not be local directory")
		}
		r.local = true
		info, err := os.Stat(remote)
		if err != nil {
			return nil, err
		}
		if !info.IsDir() {
			return nil, fmt.Errorf("%s exists but is not a directory", remote)
		}
		r.dir = remote
		r.mu.Path = r.dir + ".lock"
	}
	return r, nil
}

after:

func newGitRepo(remote string, localOK bool) (Repo, error) {
	r := &gitRepo{remote: remote}
	if strings.Contains(remote, "://") {	
		r.dir, r.mu.Path, ^ = WorkDir(gitWorkDirType, r.remote)

		unlock, ^ := r.mu.Lock()
		defer unlock()

		if _, err := os.Stat(filepath.Join(r.dir, "objects")); err != nil {
			if _, err := Run(r.dir, "git", "init", "--bare"); err != nil {
				os.RemoveAll(r.dir)
				return nil, err
			}
	
			if _, err := Run(r.dir, "git", "remote", "add", "origin", "--", r.remote); err != nil {
				os.RemoveAll(r.dir)
				return nil, err
			}
		}
		
		r.remoteURL = r.remote
		r.remote = "origin"
	} else {
		if strings.Contains(remote, ":") {
			return nil, fmt.Errorf("git remote cannot use host:path syntax")
		}
		if !localOK {
			return nil, fmt.Errorf("git remote must not be local directory")
		}
		r.local = true
		info, ^ := os.Stat(remote)
		
		if !info.IsDir() {
			return nil, fmt.Errorf("%s exists but is not a directory", remote)
		}
		r.dir = remote
		r.mu.Path = r.dir + ".lock"
	}
	return r, nil
}

"return if" seems more natural to me. It has a clear pronunciation when reading and is reminiscent of the "else if" clause already present in the language. But "return if" has the cost that, unlike "if" or "else if", it takes an error expression instead of a boolean expression. But that cost seems lower than the costs of "pass" or "return?" to me.

The cost of an error expression instead of a boolean expression after return if is high in my opinion. It can be a bit confusing because of the if keyword.

return if nil, sounds like saying return if the result of the expression is nil but that statement does the opposite. Which is why I think "pass", "return?" or something else may be better.

instead adding more complexity to the syntax, I'd propose to implement a typical try {} catch (err) {} so we don't need to capture the function return errors, but they will go directly to the catch if any function in the try returns one.

Example:

Before:

func Parse12To24h(hour12hFormat string) (int, error) {
	t, err := time.Parse("15PM", hour12hFormat)
	if err != nil {
		return -1, err
	}

	return t.Hour(), nil
}

After:

func Parse12To24h(hour12hFormat string) (int, error) {
	try {
		t := time.Parse("15PM", hour12hFormat)
	} catch (err error) {
		return -1, err
	}
	
	return t.Hour(), nil
}

This just saves us time and lines of code, whenever we have to write multiple err != nil checks

I dont like pass overlapping with return. I think pass should be used in a specific context and in a uniform way.

Here a few other ideas:

// 1.
result, pass := someFunc()

result, pass fmt.Errorf("adding more context: %v", err) := someFunc() 

// 2.
result := someFunc() pass

result := someFunc() pass fmt.Errorf("adding more context: %v", err)

However, i think we have to think about 3 things when handling errors:

1. a simple return
2. adding extra context
3. executing code in case of error

The pass solution wont handle the 3rd case (and depending of the chosen solution, not even the 2nd), and another solution would have to come in. And maybe go community would not like many different ways to handle errors.

That's why i think a catch solution like this would be more appropriate, because it would give us a single, uniform way to handle errors in all those cases.

3. executing code in case of error

I don't know if this is necessary, actually. If any extra code needs to be run, I think that it's fine to just use if err != nil { ... } like you would now. I think that a shorter syntax is fine if it only covers the common case of doing nothing but returning a potentially modified err. In fact, it might be better if it does simply so that it doesn't completely supplant the existing syntax and introduce non-orthogonal features.

That being said, I do not like the pass syntax at all. It introduces a new keyword, which breaks backwards compatibility, it's hard to read when doing anything to the error before returning, and it doesn't solve the basic issue of requiring new variables for every call that might return an error.

Honestly, I'm leaning more and more towards some kind of limited macro system to deal with this. If a macro system could be sufficiently powerful to allow you to wrap an arbitrary call that returns T, error, and that call is itself used in a larger expression, and the usage of the macro causes a return of a modified error when the error isn't nil, it solves all of the issues. If the user can define the handler macros both inline and globally, then there could be clean, reusable utility macros for common cases and more specific ones defined inline for more specific cases. For example,

func ContrivedExample(s1, s2 string) (int, error) {
  macro toInt { ... } // Bikeshedding purposefully omitted.
  return toInt(s1) + toInt(s2), nil
}

And yes, I am aware that this actually does allow arbitrary extra code, despite my first paragraph up above.

If you rename pass to rinn it will be less ambiguous and thus usable on all values; not just errors. Using the following mechanics from this proposal.

For unnamed result parameters, pass assumes their default "zero" values.

You assume default zero values for all but the error. There are ways to simplify the proposal such that this is always straightforward. For example, removing the following clause

For named result parameters, pass will return the value they already have.

Which allows security consultants to easily view the code and understand that all values will be zero; EXCEPT the passed value (if not nil).

There is another variation that can be used for explicitness; I can create it once my keyboard is no longer broken.

Otherwise, this pass proposal is our last hope.

Honestly, I'm leaning more and more towards some kind of limited macro system to deal with this.

Building on @DeedleFake 's idea, I think the key is how to limit the macro system.
It seems that the reason why error handling is hard is because there's no way to shortcut return, except for macros.
Therefore, perhaps one way to "limit" the macro system would be to support only returns.

One benefit of going with the macro the approach, is that everyone can have their favorite word, be it pass, return if etc.
This sidesteps the language keyword issue.

Implementation wise, perhaps //go:generate is something we can tap into.

Rob Pike argued in #19623 that arbitrary precision integers might be the reason for a Go 2.0.
I would wager that a macro system would be another equally powerful reason for a Go 2.0.

@fumin, the current mood of Go seems to be against macros. It might be a good solution in this case but the compiler should not become Turing complete, and macros have a high risk of being inadvertently Turing complete.

No matter what the keyword, or perhaps, built in function is named, I think the most general use is a kind of return statement that returns only of all it's returned expressions are not nil. So return? or return if, seem like good names for that.

As to the question if such a shorthand is worth while, I think it is because as @rcoreilly states, the frequency of use is the key here. My experience in Ruby which has similar expression ifs is that they are often used, very useful, and easy to read.

I have to assume this has been proposed before but I did not see it.

Why not take a lesson from if and for and define a version of return that takes a second optional arg, a boolean condition? Return is already special in that there exists a zero-argument form with named returns.

For example; we often write code that passes the error up the stack:

if x, err := foo(); err != nil { 
     return nil, err 
}
// note x and err not available here 

if we allow return to be used as

return nil, err ; err != nil

then you have a short form that short circuits and returns from the function. It doesn't change the semantics of the return expression to the left of the condition and defers etc work as before. You can mentally read this form of return as return if .

There is added potential to write expressions such as

return x, err := foo() ; err != nil 
// note x and err available here

though this last form may be a step too far.

zero argument returns continue to work, assuming the use of named arguments.

return ; err != nil 

Net introduces no new symbols or keywords and is consistent with for and if

@mdcfrancis I am afraid that it will make the code much less unreadable.
So this

f, err := os.Open(filename)
if err != nil {
       return ..., err
}
defer f.Close()

would become that

f, err := os.Open(filename)
return ..., err; err != nil
defer f.Close()

Now imagine you would like to handle it in multiple cases. How are you going to distinguish between a "legit" return or just a simple error return when looking at the left edge of the code?

To my eyes, scanning for the return keyword on the left edge tells me all the places where the function returns, and then looking to the right clarifies the conditions. I think it may indeed be easier to quickly see the flow, especially given the primary benefit of just removing lots of extra "clutter".

Under this proposal, the remaining if statements would then become actual "content" logic instead of "distracting" error-handling boilerplate, so it would also be easier to quickly see the actual function of the function..

Overall, I really like this latest proposal from @mdcfrancis!

I created a new proposal that is the same as this one but adds a second parameter for error handling so that error handling can be first class.

This proposal has the right foundation, but I believe it is a mistake to not optimize for error handling: it encourage Go programs to not annotate their errors. errors.Wrap is a creative workaround, but still leaves error handling as a second class: it obscures that err is really what is being checked and it requires reading code and looking at the calling function to ensure that it checks for nil.

There is a lot of debate about what exact keyword/syntax to use on this proposal. I would prefer to have that discussion separately and focus on getting a proposal tentatively semantically accepted with the provision that the keyword can still be changed to whatever the community decides is optimal.

It is reasonable to assume that for a new major version, you need to at least run a small command to make your code compatible.

We can certainly do this if we must. But it's a cost. We shouldn't just ignore that cost.

pass means passing the error up to the caller.

I guess. That doesn't seem like a natural meaning of "pass" to me, though. The first meaning that jumps to mind for me is to pass over something, meaning to ignore it. Any other opinions on this point?

I don't dispute that pass is more ergonomic. The thing is, we only get to change this once. We can't iterate on error handling. Is this improvement ergonomic enough?

What if we used surrender? It’s a bit longer, but seems to convey what is happening a bit more accurately.