Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: Go 2: simplify error handling - error passing with "pass" #37141

Open
xbit opened this issue Feb 8, 2020 · 29 comments
Open

proposal: Go 2: simplify error handling - error passing with "pass" #37141

xbit opened this issue Feb 8, 2020 · 29 comments

Comments

@xbit
Copy link

@xbit xbit commented Feb 8, 2020

Introduction

For the most part, I like the simplicity of error handling in Go, but I would very much like a less verbose way to pass errors.

Passing errors should still be explicit and simple enough to understand. This proposal builds on top of the many existing proposals and suggestions, and attempts to fix the problems in the proposed try built-in see design doc. Please read the original proposal if you haven't already some of the questions may already be answered there.

Would you consider yourself a novice, intermediate, or experienced Go programmer?

  • I have been using Go almost exclusively for the past two years, and I have been a developer for the past 10 years.

What other languages do you have experience with?

  • C, Java, C#, Python, Javascript, Typescript, Kotlin, Prolog, Rust, PHP ... and others that I don't remember.

Would this change make Go easier or harder to learn, and why?

  • It may make Go slightly harder to learn because its an additional keyword.

Who does this proposal help, and why?

  • This proposal helps all Go developers in their daily use of the language because it makes error handling less verbose.

Proposal

What is the proposed change?

Adding a new keyword pass.

pass expr

Pass statements may only be used inside a function with at least one result parameter where the last result is of type error.

Pass statements take an expression. The expression can be a simple error value. It can also be a function
or a method call that returns an error.

Calling pass with any other type or a different context will result in a compile-time error.

If the result of the expression is nil, pass will not perform any action, and execution continues.

If the result of the expression != nil, pass will return from the function.

  • For unnamed result parameters, pass assumes their default "zero" values.
  • For named result parameters, pass will return the value they already have.

This works similar to the proposed try built-in.

Is this change backward compatible?

Yes.

Show example code before and after the change.

A simple example:

before:

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

after:

f, err := os.Open(filename)
pass err
defer f.Close()

In the example above, if the value of err is nil. it is equivalent to calling pass in the following way (does not perform any action):

pass nil

Consequently, the following is expected to work with pass (passing a new error)

pass errors.New("some error")

Since pass accepts an expression that must be evaluated to an error . We can create handlers without any additional changes to the language.

For example, the following errors.Wrap() function works with pass.

// Wrap returns an error annotating err with a stack trace
// at the point Wrap is called, and the supplied message.
// If err is nil, Wrap returns nil.
func Wrap(err error, message string) error {
    if err == nil {
    	    return nil
    }
   err = &withMessage{
	    cause: err,
	    msg:   message,
    }
    return &withStack{
	    err,
	    callers(),
    }
}

Because Wrap returns nil when err == nil, you can use it to wrap errors:

f, err := os.Open(filename)
pass errors.Wrap(err, "couldn't open file")

the following does not perform any action (because Wrap will return nil):

 pass errors.Wrap(nil, "this pass will not return")

You can define any function that takes an error to add logging, context, stack traces ... etc.

func Foo(err Error) error {
    if err == nil {
         return nil
    }      

    // wrap the error or return a new error
}

To use it

 f, err := os.Open(filename)
 pass Foo(err)

pass is designed specifically for passing errors and nothing else.

Other examples:

(Example updated to better reflect different usages of pass)

Here's an example in practice. Code from codehost.newCodeRepo() (found by searching for err != nil - comments removed)

This example shows when it's possible to use pass, and how it may look like in the real world.

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, "://") {	
		var err error
		r.dir, r.mu.Path, err = WorkDir(gitWorkDirType, r.remote)
		pass err

		unlock, err := r.mu.Lock()
		pass 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)
				pass err
			}
	
			if _, err := Run(r.dir, "git", "remote", "add", "origin", "--", r.remote); err != nil {
				os.RemoveAll(r.dir)
				pass err
			}
		}
		
		r.remoteURL = r.remote
		r.remote = "origin"
	} else {
		if strings.Contains(remote, ":") {
			pass fmt.Errorf("git remote cannot use host:path syntax")
		}
		if !localOK {
			pass fmt.Errorf("git remote must not be local directory")
		}
		r.local = true
		info, err := os.Stat(remote)
		pass err
		
		if !info.IsDir() {
			pass fmt.Errorf("%s exists but is not a directory", remote)
		}
		r.dir = remote
		r.mu.Path = r.dir + ".lock"
	}
	return r, nil
}

What is the cost of this proposal? (Every language change has a cost).

  • How many tools (such as vet, gopls, gofmt, goimports, etc.) would be affected?

Because this is a new keyword, I'm not sure how much some of these tools would be affected,
but they shouldn't need any significant changes.

  • What is the compile time cost?

Compile time cost may be affected because the compiler may need to
perform additional optimizations to function or method calls used with pass.

  • What is the run time cost?

This depends on the implementation. Simple expressions like this:

pass err

should have equivalent runtime cost to the current err != nil.

However, function or method calls will add run time cost and this will largely depend on the implementation.

Can you describe a possible implementation?

For the simple case, the compiler may be able to expand pass statements

pass err

to

if err != nil {
    return result paramters ...
}

For function or method calls there maybe a better way to do it
possibly inline these calls for common cases?

How would the language spec change?

The new keyword pass must be added to the language spec with a more formal definition.

Orthogonality: how does this change interact or overlap with existing features?

In some cases, pass may overlap with a return statement.

func someFunc() error {
    if cond {
        pass errors.New("some error") 
    }  
    ...   

instead of

func someFunc() error {
    if cond {
        return errors.New("some error") 
    }
    ...  

It may not be clear which keyword should be used here.
pass is only useful in these cases when there is multiple result parameters.

func someFunc() (int, int, error) {
    if cond {
        pass errors.New("some error") 
    }
    ...  

instead of

func someFunc() (int, int, error) {
    if cond {
        return 0, 0, errors.New("some error") 
    }  
    ...

(Edited to make example more clear)

Is the goal of this change a performance improvement?

No

Does this affect error handling?

Yes, here is the following advantages of pass and how it may differ from other proposals.

Advantages to using pass

  • pass is still explicit.
  • Supports wrapping errors and using simple handlers without new keywords such handle ... etc.
  • it makes it easier to scan code. Avoids confusing err == nil with err != nil. Since pass only returns when error is not nil in all cases.
  • should work fairly easily with existing error handling libraries.
  • should work with breakpoints
  • much less verbose.
  • Fairly simple to understand.

Is this about generics?

No

Edit: Updated to follow the template

@gopherbot gopherbot added this to the Proposal milestone Feb 8, 2020
@gopherbot gopherbot added the Proposal label Feb 8, 2020
@ianlancetaylor ianlancetaylor changed the title proposal: Go 2 simplify error handling - error passing with "pass" proposal: Go 2: simplify error handling - error passing with "pass" Feb 8, 2020
@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Feb 8, 2020

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

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Feb 8, 2020

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!

@xbit
Copy link
Author

@xbit xbit commented Feb 9, 2020

@gopherbot please remove label WaitingForInfo

@xbit
Copy link
Author

@xbit xbit commented Feb 9, 2020

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()
@MaxSem
Copy link

@MaxSem MaxSem commented Feb 9, 2020

Why not go one step further and do something like:

result, pass err := someFunc()
@yiyus
Copy link

@yiyus yiyus commented Feb 9, 2020

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.

@xbit
Copy link
Author

@xbit xbit commented Feb 9, 2020

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

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Feb 25, 2020

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?

@rcoreilly
Copy link

@rcoreilly rcoreilly commented Feb 26, 2020

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

@proyb6
Copy link

@proyb6 proyb6 commented Feb 26, 2020

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
}
@xbit
Copy link
Author

@xbit xbit commented Feb 27, 2020

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

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Feb 27, 2020

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?

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Feb 27, 2020

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

@rcoreilly
Copy link

@rcoreilly rcoreilly commented Feb 27, 2020

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

@xbit
Copy link
Author

@xbit xbit commented Feb 27, 2020

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.

@DeedleFake
Copy link

@DeedleFake DeedleFake commented Feb 28, 2020

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.

@xbit
Copy link
Author

@xbit xbit commented Feb 28, 2020

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

@TwinProduction
Copy link

@TwinProduction TwinProduction commented Feb 28, 2020

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.

@xbit
Copy link
Author

@xbit xbit commented Feb 28, 2020

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

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Mar 10, 2020

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?

@OneOfOne
Copy link
Contributor

@OneOfOne OneOfOne commented Mar 10, 2020

@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
}
@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Mar 10, 2020

Lazy evaluation of the call seems very hard to specify. It looks fairly straightforward when the call is always errors.Wrap, but it could be anything. And the error could be any argument, or it might not even be passed at all.

@xbit
Copy link
Author

@xbit xbit commented Mar 11, 2020

@OneOfOne there is also a solution that @ianlancetaylor suggested. The compiler can look for

if err == nil {
    return nil
}

at the start of a function used in the expr and pull those lines into the caller (this happens at compile time). This makes pass have pretty much the same runtime performance as err != nil in most cases even when function calls are involved.

@rcoreilly
Copy link

@rcoreilly rcoreilly commented Mar 11, 2020

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?

I think several comments tried to address this: the main complaint is that the current solution is a) very high frequency; and b) takes 3 lines. Doing the math, eliminating 2 lines would save a lot of lines over the entire Go codebase (someone could presumably compute exactly how many -- it might be a remarkably large number -- anyone familiar with that Go language analysis tool that someone posted a few months back on the go-nuts list?).

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.

this is why I favor the return if syntax because it minimizes this concern: it is just a shorthand way of expressing the exact same control flow that everyone is familiar with. Its only point is to save those 2 lines!

The compiler optimization @xbit mentions above is just that: a compiler optimization, but not fundamentally a new flow control.

@ChrisHines
Copy link
Contributor

@ChrisHines ChrisHines commented Mar 11, 2020

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.

@bserdar
Copy link

@bserdar bserdar commented Apr 1, 2020

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.

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Apr 1, 2020

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

@blakewatters
Copy link

@blakewatters blakewatters commented May 11, 2020

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
}
@xbit
Copy link
Author

@xbit xbit commented Aug 7, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.