proposal: Go 2: make named return parameter assignment on last line a terminating statement of a function

[StephanVerbeeck]

Consider the following 2 alternatives for implementing the same function that returns a result value. The second syntax is my favorite and I use it throughout my code (I am currently developing a commercial accounting application in GOlang (based on lxn/walk)).

func Sum(a, b int) int {
	return a + b
}

func Sum(a, b int) (total int) {
	total = a + b
}

But when using the predefined variable it seems very illogical to me that GO complains about leaving out the final return statement so I must correct this by doing this:

func Sum(a, b int) (total int) {
	total = a + b
	return
}

My proposal is to NOT generate the "missing return at end of function" error in the latter case allowing programmers to leave out this obviously superfluous line of code.

[DeedleFake]

This is not going to be a popular proposal. There's been a lot of discussion about not even allowing that last example, as it's very easy to write buggy code with it, even with the shadowed during return error that currently exists. Making it possible to not even have a return statement at all is simply a step towards even more potential confusion with basically no benefits.

[randall77]

@DeedleFake What shadowed during return error?

[DeedleFake]

The following code fails to compile:

func example(t int) (v string) {
	if t > 3 {
		v := 3
		return
	}
	return
}

[StephanVerbeeck]

The following code fails to compile:

func example(t int) (v string) {
	if t > 3 {
		v := 3
		return
	}
	return
}

sure it does not compile, because it is wrong
why do you declare a new variable with the same name as your output argument?
Function arguments are already declared so there is not need for "var" or" :="

[StephanVerbeeck]

This is not going to be a popular proposal. There's been a lot of discussion about not even allowing that last example, as it's very easy to write buggy code with it, even with the shadowed during return error that currently exists. Making it possible to not even have a return statement at all is simply a step towards even more potential confusion with basically no benefits.

ok that is a valid argument but it depends also on your viewpoint.
In go you have 3 places where you can declare a function argument

• before the function name if the function is a method of that argument type
• behind the function name for the input arguments
• behind the input argument for the output arguments

If you consider a function to be a lambda expression then there are just input arguments and output arguments but not necessarily a return. Why treat input arguments different than the output arguments.
Does anybody of you feel the need to write

func MyExample(a,b,c int) (d,e int) {
	receive a,b,c
	d = a + b
	e = b + c
	return d,e
}

or

func MyExample(a,b,c int) (d,e int) {
	input a,b,c
	d = a + b
	e = b + c
	output d,e
}

or

func MyExample {
	input a,b,c
	d = a + b
	e = b + c
	output d,e
}

No you would not want to write your functions like that. But then what is the logic behind that "feeling".

What is the reason (other then habit of previous millennium) to have an end-of-function indicator at the end of the function? Because I have the feeling that I write an assembler RET instruction at the end of the functions which feels to me totally out of place and out of style in a modern language like GO.

Are we keeping that return statement just because we "feel" we have to keep it?

And please do not suggest to drop the syntax to declare the output arguments with the input arguments (because that was a great idea and I love the consistency that it introduces).

[DeedleFake]

sure it does not compile, because it is wrong
why do you declare a new variable with the same name as your output argument?
Function arguments are already declared so there is not need for "var" or" :="

I know. I was answering @randall77's question.

And there are plenty of reasons to redeclare a variable with the same name. The most common, probably, is if you have a named error return. For contrived example:

func Example(q bool) (err error) {
  if q {
    file, err := os.Open("file.txt")
    if err != nil {
      // The compiler will catch this for you, even though there's
      // technically nothing wrong with the code, simply because
      // it's highly likely that it's an error.
      return
    }
    defer file.Close()
  }
  // Do something else...
}

[ianlancetaylor]

What if there are multiple result parameters?

An explicit return is a good marker for where the result parameters become the actual results. We aren't going to make this change.