Discussion:
plan for return requirements
(too old to reply)
Russ Cox
2013-03-01 04:48:01 UTC
Permalink
For Go 1.1 we propose to specify when a function requires a return
statement. The 6g and gccgo compilers agree today, by design, but the
details have never been part of the spec. At the same time, we propose to
make the requirements a little less strict.

The details are at http://golang.org/s/go11return. Comments are welcome in
this thread.

Thanks.
Russ
--
---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
andrey mirtchovski
2013-03-01 05:16:12 UTC
Permalink
offtopic, sorry, but:

"In total, I downloaded 38,734 Go source files containing 8,330,489 lines."

unique? wow!
--
---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Russ Cox
2013-03-01 05:25:55 UTC
Permalink
On Fri, Mar 1, 2013 at 12:16 AM, andrey mirtchovski
Post by andrey mirtchovski
"In total, I downloaded 38,734 Go source files containing 8,330,489 lines."
unique? wow!
Hard to say. There are definitely some dups. For example camlistore
includes a bunch of other projects. I put a copy of the go source files
only (not the .git and .hg directories and not any non-go files) at
https://code.google.com/p/rsc/downloads/detail?name=pubgo.zip. 66 MB
compressed, 225 MB uncompressed.

Russ
--
---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Andrew Wilkins
2013-03-01 07:30:31 UTC
Permalink
Post by Russ Cox
For Go 1.1 we propose to specify when a function requires a return
statement. The 6g and gccgo compilers agree today, by design, but the
details have never been part of the spec. At the same time, we propose to
make the requirements a little less strict.
The details are at http://golang.org/s/go11return. Comments are welcome
in this thread.
I don't have much to say, other than SGTM. Will these rules be added to
go/types?
I can't think of any good reason to implement alternative three, seems to
be excessive for little gain.
Alternative four sounds like it'd cause more problems than it'd solve.

Cheers,
Andrew
--
---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Robert Griesemer
2013-03-01 14:16:06 UTC
Permalink
Yes, I plan to add checking for the new return rules in go/types very soon.
- gri
Post by Andrew Wilkins
Post by Russ Cox
For Go 1.1 we propose to specify when a function requires a return
statement. The 6g and gccgo compilers agree today, by design, but the
details have never been part of the spec. At the same time, we propose to
make the requirements a little less strict.
The details are at http://golang.org/s/go11return**. Comments are
welcome in this thread.
I don't have much to say, other than SGTM. Will these rules be added to
go/types?
I can't think of any good reason to implement alternative three, seems to
be excessive for little gain.
Alternative four sounds like it'd cause more problems than it'd solve.
Cheers,
Andrew
--
---
You received this message because you are subscribed to the Google Groups
"golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/groups/opt_out.
--
---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Russ Cox
2013-03-01 14:23:54 UTC
Permalink
There is an implementation of these rules over the go/ast in CL 7440047.
The label handling should be done better; it's what I used for the analysis.

Russ
--
---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Jan Mercl
2013-03-01 08:55:54 UTC
Permalink
Post by Russ Cox
For Go 1.1 we propose to specify when a function requires a return
statement. The 6g and gccgo compilers agree today, by design, but the
details have never been part of the spec. At the same time, we propose to
make the requirements a little less strict.
The details are at http://golang.org/s/go11return. Comments are welcome in
this thread.
"The godoc.org web site listed 6,021 known open source Go packages,
and I downloaded all the ones I could using “go get.” In total, I
downloaded 38,734 Go source files containing 8,330,489 lines."

"In total, there are 2,112 function-ending panics in the source files."

2,112 such functions in 38,734 Go source files is about 1 such
function in 18 Go source files (and cca only one per three packages).
One Go source file typically consists of more than one function. Let
me estimate there are at least 5 funcs/package on average.

Whatever the resolution is going to be, it can improve the life of
perhaps not even 1% of function written out there. Which I'm not sure
is worth of the effort.

-j

PS: Local numbers:

(09:45) ***@fsc-r550:~/src/github.com/cznic$ grep -nr
'panic("unreachable")' * | wc -l
59
(09:45) ***@fsc-r550:~/src/github.com/cznic$ find -name \*.go | wc -l
166
(09:45) ***@fsc-r550:~/src/github.com/cznic$
--
---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
roger peppe
2013-03-01 10:32:59 UTC
Permalink
Post by Russ Cox
For Go 1.1 we propose to specify when a function requires a return
statement. The 6g and gccgo compilers agree today, by design, but the
details have never been part of the spec. At the same time, we propose to
make the requirements a little less strict.
The details are at http://golang.org/s/go11return. Comments are welcome in
this thread.
looks great to me.
--
---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Michael Jones
2013-03-01 14:15:35 UTC
Permalink
Russ, one comment on "...or return the current values of the named return
parameters on reaching the end." This case, once that I was going to
mention in your definition at the top of the proposal, makes sense to me
even though your next sentence says you don't like it. Here's why I do:

a. A function with named result parameters by the spec has those values set
to their zero vales before the body of the function is entered. Having
those values returned to the caller upon function return is of course the
rule of the spec as well. This means that a call-return with no changing of
the value of these return parameters is completely defined by the spec and
consistent, i.e., not a "fault" to be caught.

b. Such functions can the values of their return parameters directly with
"paramName = value; ...; return" or indirectly with "return value" where
the second feels a shorthand for the former. In neither case is there doubt
about the meaning or unclarity in the code.

c. The end of any subroutine is the return to its caller. This is
axiomatic. So too is returning the named parameter values to the caller. The
"I'm returning now" of a bare "return" before the final "}" as at present
feels redundant to me. Where else was the function going to go with the
program counter other than back to the caller? What else was going to be
returned other than the named parameters whose values were already
established? It feels like stuttering to me.

That's why I'm a fan of implicit return for named result value functions. I
would change the spec to say, "The *return* statement is optional in
functions with named result parameters. Using it causes an assignment to
all result parameters before returning to the caller."
Post by roger peppe
Post by Russ Cox
For Go 1.1 we propose to specify when a function requires a return
statement. The 6g and gccgo compilers agree today, by design, but the
details have never been part of the spec. At the same time, we propose to
make the requirements a little less strict.
The details are at http://golang.org/s/go11return. Comments are welcome
in
Post by Russ Cox
this thread.
looks great to me.
--
---
You received this message because you are subscribed to the Google Groups
"golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/groups/opt_out.
--
Michael T. Jones | Chief Technology Advocate | mtj-hpIqsD4AKlfQT0dZR+***@public.gmane.org | +1
650-335-5765
--
---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
benjamin.ellis-L7J+
2013-03-01 18:53:47 UTC
Permalink
+1 to Michael's tweak,
+1 to the proposed definition with the tweak.
Post by Michael Jones
Russ, one comment on "...or return the current values of the named return
parameters on reaching the end." This case, once that I was going to
mention in your definition at the top of the proposal, makes sense to me
a. A function with named result parameters by the spec has those values
set to their zero vales before the body of the function is entered. Having
those values returned to the caller upon function return is of course the
rule of the spec as well. This means that a call-return with no changing of
the value of these return parameters is completely defined by the spec and
consistent, i.e., not a "fault" to be caught.
b. Such functions can the values of their return parameters directly with
"paramName = value; ...; return" or indirectly with "return value" where
the second feels a shorthand for the former. In neither case is there doubt
about the meaning or unclarity in the code.
c. The end of any subroutine is the return to its caller. This is
axiomatic. So too is returning the named parameter values to the caller. The
"I'm returning now" of a bare "return" before the final "}" as at present
feels redundant to me. Where else was the function going to go with the
program counter other than back to the caller? What else was going to be
returned other than the named parameters whose values were already
established? It feels like stuttering to me.
That's why I'm a fan of implicit return for named result value functions.
I would change the spec to say, "The *return* statement is optional in
functions with named result parameters. Using it causes an assignment to
all result parameters before returning to the caller."
Post by Russ Cox
Post by Russ Cox
For Go 1.1 we propose to specify when a function requires a return
statement. The 6g and gccgo compilers agree today, by design, but the
details have never been part of the spec. At the same time, we propose
to
Post by Russ Cox
make the requirements a little less strict.
The details are at http://golang.org/s/go11return. Comments are
welcome in
Post by Russ Cox
this thread.
looks great to me.
--
---
You received this message because you are subscribed to the Google Groups
"golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/groups/opt_out.
--
| +1 650-335-5765
--
---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Rob Pike
2013-03-01 19:12:45 UTC
Permalink
For the record I disagree with the proposal to assume a naked return
at the end of a function because I have often made the mistake of
forgetting the return outright and as often as not the current values
of the named return parameters are not the ones I mean to return.

-rob, channeling Gertrude Stein
--
---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Russ Cox
2013-03-01 19:26:58 UTC
Permalink
Also many functions name parameters for documentation purposes only, with
no intention of using the naked return.

Russ
--
---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Michael Jones
2013-03-01 20:07:16 UTC
Permalink
Rob and Russ make good arguments. Much of Go is about minimizing risks of
error and confusion. If this is one of those areas then I have a counter
proposal--not counter to yours but to mine. ;-) If the implicit return
scares you then why not disallow the bare return for named arguments too --
force the programmer to say "I am returning now" and also "I am sending
SQRT and ERROR to the caller." It could always be done by echoing the
return value names in the return statement:

func x(...) (a int, b float64) {
:
a = 7
:
if ... { a = 9 }
:
b = ...
:

return a, b
}

This way there would be nothing to forget.
Post by Russ Cox
Also many functions name parameters for documentation purposes only, with
no intention of using the naked return.
Russ
650-335-5765
--
---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Russ Cox
2013-03-01 20:09:38 UTC
Permalink
There's probably a case to be made and a discussion that could be had. But
having allowed the naked 'return' in Go 1, we are not in a position now to
remove it.

Russ
--
---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Michael Jones
2013-03-01 20:13:02 UTC
Permalink
Of course. Sorry. Well, then I can only say that your proposal is very nice
as originally written! ;-)
Post by Russ Cox
There's probably a case to be made and a discussion that could be had. But
having allowed the naked 'return' in Go 1, we are not in a position now to
remove it.
Russ
Michael T. Jones | Chief Technology Advocate | mtj-hpIqsD4AKlfQT0dZR+***@public.gmane.org | +1
650-335-5765
--
---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Michael Jones
2013-03-01 22:00:02 UTC
Permalink
Delayed realization ... go vet or fmt could "clothe" naked returns with the
formal parameter names, then Rob's concerns would be assuaged and any
code--sans such polishing--would still be Go 1 compliant. There can be no
doubt about this since the names have been parsed at the top and are there
to be appended at the bottom...
Post by Michael Jones
Of course. Sorry. Well, then I can only say that your proposal is very
nice as originally written! ;-)
Post by Russ Cox
There's probably a case to be made and a discussion that could be had.
But having allowed the naked 'return' in Go 1, we are not in a position now
to remove it.
Russ
650-335-5765
--
Michael T. Jones | Chief Technology Advocate | mtj-hpIqsD4AKlfQT0dZR+***@public.gmane.org | +1
650-335-5765
--
---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Russ Cox
2013-03-01 22:21:15 UTC
Permalink
Post by Michael Jones
Delayed realization ... go vet or fmt could "clothe" naked returns with
the formal parameter names, then Rob's concerns would be assuaged and any
code--sans such polishing--would still be Go 1 compliant. There can be no
doubt about this since the names have been parsed at the top and are there
to be appended at the bottom...
FWIW, due to shadowed variables, one cannot always do this. The return
variable may not be visible in the scope of the return statement.

Russ
--
---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Steven Blenkinsop
2013-03-02 02:12:20 UTC
Permalink
Post by Russ Cox
Post by Michael Jones
Delayed realization ... go vet or fmt could "clothe" naked returns with
the formal parameter names, then Rob's concerns would be assuaged and any
code--sans such polishing--would still be Go 1 compliant. There can be no
doubt about this since the names have been parsed at the top and are there
to be appended at the bottom...
FWIW, due to shadowed variables, one cannot always do this. The return
variable may not be visible in the scope of the return statement.
Russ
The implementation (Go 1.0) already disallows naked return statements with
shadowed return variables, unless this is changing in Go 1.1.
--
---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Russ Cox
2013-03-02 16:35:28 UTC
Permalink
Post by Steven Blenkinsop
The implementation (Go 1.0) already disallows naked return statements with
shadowed return variables, unless this is changing in Go 1.1.
Indeed. That's not changing (and naked returns aren't going away either).

Russ
--
---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
mg
2013-03-01 13:53:44 UTC
Permalink
At the same time, we propose to make the requirements a little less strict.
In my opinion the current behaviour is acceptable, further complicating
the spec is not worth it. At least I don't have to additionally
remember or teach the less strict rules ;-)

Ermm, my very naive feeling is, the Go tool chain could (as with the
semicolon)
do the panic() legwork.

Martin
--
---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
s***@public.gmane.org
2013-03-01 20:16:15 UTC
Permalink
Post by Russ Cox
For Go 1.1 we propose to specify when a function requires a return
statement. The 6g and gccgo compilers agree today, by design, but the
details have never been part of the spec. At the same time, we propose to
make the requirements a little less strict.
The details are at http://golang.org/s/go11return. Comments are welcome
in this thread.
Thanks.
Russ
How specifically do you want to specify the boundary conditions involving
labelled statements, empty statements, and empty block statements? Here are
examples using the current behaviour:
http://play.golang.org/p/d7rr3YftpC

Maybe specify that labelled terminating statements are themselves
terminating statements, that labelled empty statements are not themselves
empty statements, and then talk about the last *non-empty* statement rather
than just the last statement. I'm not sure about whether the compiler
should be ignoring empty block statements, or how to specify this
behaviour. Possibly "{" { EmptyStmt ";" } "}" could be classified as an
empty statement as well as a block statement, though I'm not sure this is
worthwhile or desirable.
--
---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
n***@public.gmane.org
2013-03-01 21:33:49 UTC
Permalink
I am in favor of Russ' change to the spec (all 1-8). This statement
particularly resonated with me:

"the solution today is to end both with panic(“unreachable”). At least when
I do that, I always have the nagging concern that maybe I have made a
mistake and the bottom of the function really is reachable. I would rather
the compiler confirm my understanding by accepting the code without the
panic."

I want the compiler to help find my errors. I don't want to have to guess
if the end of the function is reachable or not.

for example, if I have:

switch foo() {
case 1:
return "A"
case 2:
return "B"
default:
return "C"
}

panic("unreachable")

If I then make/merge in some changes that remove the default... the code
still compiles, and I might not notice until runtime (which could mean
production). On the other hand, with these changes, then I wouldn't put
the panic there, and removing the default would (correctly) cause a
compilation error.

The added complexity to the spec is minimal, and most strongly typed
languages function similarly, so it's not like this is going to be a part
of the spec people are agonizing over... it'll work the way people expect,
as opposed to the current behavior, which is not what people expect, so
they then try to find it in the spec, and then argue about it on this
mailing list :)
--
---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Dan Kortschak
2013-03-02 21:13:55 UTC
Permalink
I'd like to put forward support for the second alternative, excluding items 5 and 8. I believe that 5 and 8 are orthogonal to the problem noted in Issue 65. As Russ notes, it is easy to avoid the requirement for an artificial panic with the current implementation, and I don't believe that the items' exclusion does result in an irregularity.

Dan
--
---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Dave Cheney
2013-03-02 21:31:14 UTC
Permalink
Despite being possibly being labeled a stick in the mud, I throw my
hat in the ring for the first alternative, documenting rules 1 through
4, the current behavior.

On consideration, I believe that most cases where panic("unreachable")
is used could be rewritten to avoid the panic under rules 1 through 4,
and those that cannot must be so complex that the presence of a panic
is a signal to the reader to exercise caution.

Dave

On Sun, Mar 3, 2013 at 8:13 AM, Dan Kortschak
Post by Dan Kortschak
I'd like to put forward support for the second alternative, excluding items 5 and 8. I believe that 5 and 8 are orthogonal to the problem noted in Issue 65. As Russ notes, it is easy to avoid the requirement for an artificial panic with the current implementation, and I don't believe that the items' exclusion does result in an irregularity.
Dan
--
---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
For more options, visit https://groups.google.com/groups/opt_out.
--
---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Kyle Lemons
2013-03-03 02:44:03 UTC
Permalink
Post by Dan Kortschak
I'd like to put forward support for the second alternative, excluding
items 5 and 8. I believe that 5 and 8 are orthogonal to the problem noted
in Issue 65. As Russ notes, it is easy to avoid the requirement for an
artificial panic with the current implementation, and I don't believe that
the items' exclusion does result in an irregularity.
For what it's worth, I share a mild preference for requiring unnecessary
else and default clauses to be removed, but I understand that it would be a
non-orthogonality, and I don't mind leaving it as a stylistic point that I
enforce when doing code reviews.
Post by Dan Kortschak
Dan
--
---
You received this message because you are subscribed to the Google Groups
"golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/groups/opt_out.
--
---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Robert Griesemer
2013-03-03 02:55:03 UTC
Permalink
Here's another way of looking at this proposal. In essence it says:

a) return, goto, and panic are terminating
b) a single branch of control flow is terminating if the last statement in
the branch is terminating.
c) a composite statement is terminating if all its branches of control flow
are terminating.

The status quo is a) and b). The proposal adds c).

Rather simple and straight-forward.

Rule 5 and 8 are different sides of the same coin: An if is a switch is an
if. So we can just talk about item 5 (if's.)

Without rule 5 (and thus 8), rule 6 seems out of place: Loops w/o
conditions are relatively rare; and theoretically, a loop can be written
recursively with a conditional, hence rule 6 can be seen as a variant of
rule 5. That leaves rule 7, but select statements are even more rare
relative to other statements, so why bother?

So the question really is: are we happy with the status quo, or do we want
all statements be treated equally and add rule c). I think that is a valid
question. If we believe the proposal is solving a real issue, we should
consider it as a whole.

Personally, I believe the proposal solves a real issue, and I don't want
the language to tell me how to write my if's or switches, as long as they
are correct (even though I may favor the non-else style myself). There are
reasons on occasion where a symmetric if may be better, for pedagogic,
documentation, or other reasons.

- gri
Post by Dan Kortschak
I'd like to put forward support for the second alternative, excluding
items 5 and 8. I believe that 5 and 8 are orthogonal to the problem noted
in Issue 65. As Russ notes, it is easy to avoid the requirement for an
artificial panic with the current implementation, and I don't believe that
the items' exclusion does result in an irregularity.
Dan
--
---
You received this message because you are subscribed to the Google Groups
"golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/groups/opt_out.
--
---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Dan Kortschak
2013-03-03 03:14:20 UTC
Permalink
Thank you for that perspective on it, it makes it clearer in my mind why Russ sees it as an irregularity.

On 03/03/2013, at 1:25 PM, "Robert Griesemer" <gri-iFWiy5xATs8dnm+***@public.gmane.org<mailto:***@golang.org>> wrote:

Here's another way of looking at this proposal. In essence it says:

a) return, goto, and panic are terminating
b) a single branch of control flow is terminating if the last statement in the branch is terminating.
c) a composite statement is terminating if all its branches of control flow are terminating.

The status quo is a) and b). The proposal adds c).

Rather simple and straight-forward.

Rule 5 and 8 are different sides of the same coin: An if is a switch is an if. So we can just talk about item 5 (if's.)

Without rule 5 (and thus 8), rule 6 seems out of place: Loops w/o conditions are relatively rare; and theoretically, a loop can be written recursively with a conditional, hence rule 6 can be seen as a variant of rule 5. That leaves rule 7, but select statements are even more rare relative to other statements, so why bother?

So the question really is: are we happy with the status quo, or do we want all statements be treated equally and add rule c). I think that is a valid question. If we believe the proposal is solving a real issue, we should consider it as a whole.

Personally, I believe the proposal solves a real issue, and I don't want the language to tell me how to write my if's or switches, as long as they are correct (even though I may favor the non-else style myself). There are reasons on occasion where a symmetric if may be better, for pedagogic, documentation, or other reasons.

- gri



On Sat, Mar 2, 2013 at 1:13 PM, Dan Kortschak <dan.kortschak-***@public.gmane.orgu<mailto:dan.kortschak-sKtvjTG20lXX/***@public.gmane.org>> wrote:
I'd like to put forward support for the second alternative, excluding items 5 and 8. I believe that 5 and 8 are orthogonal to the problem noted in Issue 65. As Russ notes, it is easy to avoid the requirement for an artificial panic with the current implementation, and I don't believe that the items' exclusion does result in an irregularity.

Dan

--

---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe-/***@public.gmane.org<mailto:golang-dev%2Bunsubscribe-/***@public.gmane.org>.
For more options, visit https://groups.google.com/groups/opt_out.
--
---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Robert Griesemer
2013-03-03 06:25:20 UTC
Permalink
Thanks - though just to be clear, I am not presuming to know what Russ
thinks :-) This is just how I see it.
- gri
Post by Dan Kortschak
Thank you for that perspective on it, it makes it clearer in my mind why
Russ sees it as an irregularity.
a) return, goto, and panic are terminating
b) a single branch of control flow is terminating if the last statement
in the branch is terminating.
c) a composite statement is terminating if all its branches of control
flow are terminating.
The status quo is a) and b). The proposal adds c).
Rather simple and straight-forward.
Rule 5 and 8 are different sides of the same coin: An if is a switch is
an if. So we can just talk about item 5 (if's.)
Without rule 5 (and thus 8), rule 6 seems out of place: Loops w/o
conditions are relatively rare; and theoretically, a loop can be written
recursively with a conditional, hence rule 6 can be seen as a variant of
rule 5. That leaves rule 7, but select statements are even more rare
relative to other statements, so why bother?
So the question really is: are we happy with the status quo, or do we
want all statements be treated equally and add rule c). I think that is a
valid question. If we believe the proposal is solving a real issue, we
should consider it as a whole.
Personally, I believe the proposal solves a real issue, and I don't want
the language to tell me how to write my if's or switches, as long as they
are correct (even though I may favor the non-else style myself). There are
reasons on occasion where a symmetric if may be better, for pedagogic,
documentation, or other reasons.
- gri
On Sat, Mar 2, 2013 at 1:13 PM, Dan Kortschak <
Post by Dan Kortschak
I'd like to put forward support for the second alternative, excluding
items 5 and 8. I believe that 5 and 8 are orthogonal to the problem noted
in Issue 65. As Russ notes, it is easy to avoid the requirement for an
artificial panic with the current implementation, and I don't believe that
the items' exclusion does result in an irregularity.
Dan
--
---
You received this message because you are subscribed to the Google Groups
"golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/groups/opt_out.
--
---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Dan Kortschak
2013-03-03 07:00:16 UTC
Permalink
X-Received: by 10.182.245.115 with SMTP id xn19mr643421obc.12.1362294019842;
Sat, 02 Mar 2013 23:00:19 -0800 (PST)
X-BeenThere: golang-dev-/***@public.gmane.org
Received: by 10.182.159.42 with SMTP id wz10ls956382obb.33.gmail; Sat, 02 Mar
2013 23:00:18 -0800 (PST)
X-Received: by 10.66.161.196 with SMTP id xu4mr2781220pab.27.1362294018911;
Sat, 02 Mar 2013 23:00:18 -0800 (PST)
X-Received: by 10.66.161.196 with SMTP id xu4mr2781219pab.27.1362294018903;
Sat, 02 Mar 2013 23:00:18 -0800 (PST)
Received: from smtp-out-01.adelaide.edu.au (smtp-out-01.adelaide.edu.au. [129.127.252.129])
by gmr-mx.google.com with ESMTP id tj3si3980974pbc.0.2013.03.02.23.00.18;
Sat, 02 Mar 2013 23:00:18 -0800 (PST)
Received-SPF: pass (google.com: best guess record for domain of dan.kortschak-sKtvjTG20lXX/***@public.gmane.org designates 129.127.252.129 as permitted sender) client-ip=129.127.252.129;
X-SBRS: None
X-Listener: MTA_SMTP
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ap8EAJbzMlEKAD4T/2dsb2JhbABEwkqBEXOCHwEBBAE6PwULAgEIDigQMiUBAQQOBYgNt3+IZI5qMweCX2EDqjo
X-IronPort-AV: E=Sophos;i="4.84,771,1355059800";
d="scan'208";a="61916015"
Received: from mailht03.ad.adelaide.edu.au ([10.0.62.19])
by terrier-private.services.adelaide.edu.au with ESMTP; 03 Mar 2013 17:30:17 +1030
Received: from MAILMB04.ad.adelaide.edu.au ([fe80::d021:c074:294:231b]) by
mailht03.ad.adelaide.edu.au ([::1]) with mapi id 14.02.0318.001; Sun, 3 Mar
2013 17:30:17 +1030
Thread-Topic: [golang-dev] Re: plan for return requirements
Thread-Index: Ac4Xiti8qipkZOLURai4+teg6KnHLf//r0qAgAC1aSH//4VYAIAAucjg
In-Reply-To: <CAKy0tf5VdzcCBBVvXFDw-O8JVRRK=4w0mSRD5ed0y4rioye5Cw-JsoAwUIsXosN+***@public.gmane.org>
Accept-Language: en-AU, en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
X-Original-Sender: dan.kortschak-sKtvjTG20lXX/***@public.gmane.org
X-Original-Authentication-Results: gmr-mx.google.com; spf=pass
(google.com: best guess record for domain of dan.kortschak-sKtvjTG20lXX/***@public.gmane.org
designates 129.127.252.129 as permitted sender) smtp.mail=dan.kortschak-sKtvjTG20lXX/***@public.gmane.org
Precedence: list
Mailing-list: list golang-dev-/***@public.gmane.org; contact golang-dev+owners-/***@public.gmane.org
List-ID: <golang-dev.googlegroups.com>
X-Google-Group-Id: 1097896213209
List-Post: <http://groups.google.com/group/golang-dev/post?hl=en_US>, <mailto:golang-dev-/***@public.gmane.org>
List-Help: <http://groups.google.com/support/?hl=en_US>, <mailto:golang-dev+help-/***@public.gmane.org>
List-Archive: <http://groups.google.com/group/golang-dev?hl=en_US>
Sender: golang-dev-/***@public.gmane.org
List-Subscribe: <http://groups.google.com/group/golang-dev/subscribe?hl=en_US>,
<mailto:golang-dev+subscribe-/***@public.gmane.org>
List-Unsubscribe: <http://groups.google.com/group/golang-dev/subscribe?hl=en_US>,
<mailto:googlegroups-manage+1097896213209+unsubscribe-/***@public.gmane.org>
Content-Language: en-US
Archived-At: <http://permalink.gmane.org/gmane.comp.lang.go.devel/61567>

No, of course. Thinking on it further, the three points you made would be a good preface to the spec rules, as a explanation for why the rules are what they are.
Thanks - though just to be clear, I am not presuming to know what Russ thinks :-) This is just how I see it.
--
---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Russ Cox
2013-03-04 14:52:42 UTC
Permalink
Post by Jan Mercl
2,112 such functions in 38,734 Go source files is about 1 such
function in 18 Go source files (and cca only one per three packages).
One Go source file typically consists of more than one function. Let
me estimate there are at least 5 funcs/package on average.
Whatever the resolution is going to be, it can improve the life of
perhaps not even 1% of function written out there. Which I'm not sure
is worth of the effort.
In my opinion the current behaviour is acceptable, further complicating
the spec is not worth it. At least I don't have to additionally
remember or teach the less strict rules ;-)
On consideration, I believe that most cases where panic("unreachable")
is used could be rewritten to avoid the panic under rules 1 through 4,
and those that cannot must be so complex that the presence of a panic
is a signal to the reader to exercise caution.
(and others not quoted)

Thanks for all the feedback.

I understand this general point of view, and to some extent I sympathize
with it, but I believe the data is on the side of fixing things.

It is true that there the 2,112 panics are a small fraction of the tree I
examined, but even low-frequency constructs can have a significant impact
on the feel of the language. That same tree has fewer than 3,000 select
statements. A more compelling stat is that of the panics mentioning words
like "reachable" or "never", this proposal eliminates the need for 75%. And
of the ones that are actually unreachable, even in the presence of
unexpected inputs, the proposal eliminates very nearly 100%.

The bulk of the effort is in gathering data and deciding what to do, both
of which are fixed costs and almost fully paid. The ongoing costs of
implementing and remembering the rule are more important, and the design is
intended to minimize these. I actually believe the new rule is easier to
teach and remember than the current ones. It can be stated as follows: if
you can tell just from the *shape* of last statement (that is, ignoring the
types and values involved) that it always redirects control away from the
closing }, then the function is terminated properly; otherwise the function
is missing a return. Today we have the very same rule, with special cases
excluding the examination of if, for, switch, and select statements. I
think that's harder to learn and to remember. In fact with the new rule I
think it might be reasonable to leave it unmentioned: in far more cases it
behaves exactly how people expect, much the same way you don't have to
teach what x = y + z means. Considering only the final statement - and not
everything that follows - was another conscious decision intended to reduce
the evaluation cost both for compilers and people.

Most cases where panic("unreachable") is used and eliminated by this
proposal are following non-terminating for loops (622 out of 1,007), and
that case cannot be rewritten to avoid the panic. I gave an example of such
a loop in the doc:

func readNonEmpty(c chan []byte) []byte {
for {
if p := <-c; len(p) > 0 {
return p
}
}
}

and in fact I think the code is clearer without the panic: from now on,
when you see that loop without a panic you will be able to reason "well
that for loop really must never terminate - no matter how complex it is -
because otherwise the function would not compile".

Stepping into the qualitative realm for a minute, the effect of this change
is to reduce the number of false positives for this compiler error, so that
when the compiler says a function is missing a return, it is far more
likely that it really is. This increases the signal-to-noise ratio of the
interaction with the compiler, moving Go programs one more step in the
right direction along the axis in the Dick Gabriel quote.*

Russ

* Part of his and Guy Steele's 50 in 50 talk: "At HOPL in 1978, Nygaard
called himself a research worker. I'm always delighted by the light touch
and stillness of early programming languages. Not much text; a lot gets
done. Old programs read like quiet conversations between a well-spoken
research worker and a well-studied mechanical colleague, not as a debate
with a compiler. Who'd have guessed sophistication bought such noise?"

--
---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Michael Jones
2013-03-04 15:58:22 UTC
Permalink
Absolutely a great plan. Also, on an emotional level, warnings/refusals
about non-events are irritating.
Post by Jan Mercl
2,112 such functions in 38,734 Go source files is about 1 such
Post by Jan Mercl
function in 18 Go source files (and cca only one per three packages).
One Go source file typically consists of more than one function. Let
me estimate there are at least 5 funcs/package on average.
Whatever the resolution is going to be, it can improve the life of
perhaps not even 1% of function written out there. Which I'm not sure
is worth of the effort.
In my opinion the current behaviour is acceptable, further complicating
Post by Jan Mercl
the spec is not worth it. At least I don't have to additionally
remember or teach the less strict rules ;-)
On consideration, I believe that most cases where panic("unreachable")
is used could be rewritten to avoid the panic under rules 1 through 4,
and those that cannot must be so complex that the presence of a panic
is a signal to the reader to exercise caution.
(and others not quoted)
Thanks for all the feedback.
I understand this general point of view, and to some extent I sympathize
with it, but I believe the data is on the side of fixing things.
It is true that there the 2,112 panics are a small fraction of the tree I
examined, but even low-frequency constructs can have a significant impact
on the feel of the language. That same tree has fewer than 3,000 select
statements. A more compelling stat is that of the panics mentioning words
like "reachable" or "never", this proposal eliminates the need for 75%. And
of the ones that are actually unreachable, even in the presence of
unexpected inputs, the proposal eliminates very nearly 100%.
The bulk of the effort is in gathering data and deciding what to do, both
of which are fixed costs and almost fully paid. The ongoing costs of
implementing and remembering the rule are more important, and the design is
intended to minimize these. I actually believe the new rule is easier to
teach and remember than the current ones. It can be stated as follows: if
you can tell just from the *shape* of last statement (that is, ignoring
the types and values involved) that it always redirects control away from
the closing }, then the function is terminated properly; otherwise the
function is missing a return. Today we have the very same rule, with
special cases excluding the examination of if, for, switch, and select
statements. I think that's harder to learn and to remember. In fact with
the new rule I think it might be reasonable to leave it unmentioned: in far
more cases it behaves exactly how people expect, much the same way you
don't have to teach what x = y + z means. Considering only the final
statement - and not everything that follows - was another conscious
decision intended to reduce the evaluation cost both for compilers and
people.
Most cases where panic("unreachable") is used and eliminated by this
proposal are following non-terminating for loops (622 out of 1,007), and
that case cannot be rewritten to avoid the panic. I gave an example of such
func readNonEmpty(c chan []byte) []byte {
for {
if p := <-c; len(p) > 0 {
return p
}
}
}
and in fact I think the code is clearer without the panic: from now on,
when you see that loop without a panic you will be able to reason "well
that for loop really must never terminate - no matter how complex it is -
because otherwise the function would not compile".
Stepping into the qualitative realm for a minute, the effect of this
change is to reduce the number of false positives for this compiler error,
so that when the compiler says a function is missing a return, it is far
more likely that it really is. This increases the signal-to-noise ratio of
the interaction with the compiler, moving Go programs one more step in the
right direction along the axis in the Dick Gabriel quote.*
Russ
* Part of his and Guy Steele's 50 in 50 talk: "At HOPL in 1978, Nygaard
called himself a research worker. I'm always delighted by the light touch
and stillness of early programming languages. Not much text; a lot gets
done. Old programs read like quiet conversations between a well-spoken
research worker and a well-studied mechanical colleague, not as a debate
with a compiler. Who'd have guessed sophistication bought such noise?"
http://youtu.be/Nii1n8PYLrc
--
---
You received this message because you are subscribed to the Google Groups
"golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/groups/opt_out.
--
Michael T. Jones | Chief Technology Advocate | mtj-hpIqsD4AKlfQT0dZR+***@public.gmane.org | +1
650-335-5765
--
---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Russ Cox
2013-03-05 18:54:48 UTC
Permalink
Done at tip.
--
---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Alan Donovan
2013-03-04 03:15:43 UTC
Permalink
Post by Russ Cox
For Go 1.1 we propose to specify when a function requires a return
statement. The 6g and gccgo compilers agree today, by design, but the
details have never been part of the spec. At the same time, we propose to
make the requirements a little less strict.
The details are at http://golang.org/s/go11return. Comments are welcome in
this thread.
Nice doc---sorry it took me a while to read it.

I have no quibbles with your proposed course of action, but two minor
comments on the doc:

(1) You might want to mention a sixth kind of call, even if only to
explain it away as sugar around the fifth:

type I interface { f(...) }
f := I.f // "standalone" interface method; equivalent to f :=
func(i I, ...) { return i.f(...) }
var i I
f(i, ...)

(2) The doc makes reference to the classic "two word" formulation of
closures, building the expectation that that's what you're going to
propose--but it isn't. The New Implementation section could
explicitly dismiss it briefly.

Feel free to ignore both of these comments if you don't intend the doc
to stick around after you've finished the work, but I hope that's not
the case, as it's a lucid explanation of and motivation for the new
(and soon to be current) implementation.

cheers
alan
--
---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Alan Donovan
2013-03-04 03:32:46 UTC
Permalink
Post by Alan Donovan
Post by Russ Cox
For Go 1.1 we propose to specify when a function requires a return
statement. The 6g and gccgo compilers agree today, by design, but the
details have never been part of the spec. At the same time, we propose to
make the requirements a little less strict.
The details are at http://golang.org/s/go11return. Comments are welcome in
this thread.
Nice doc---sorry it took me a while to read it.
I have no quibbles with your proposed course of action, but two minor
(1) You might want to mention a sixth kind of call, even if only to
type I interface { f(...) }
f := I.f // "standalone" interface method; equivalent to f :=
func(i I, ...) { return i.f(...) }
var i I
f(i, ...)
(2) The doc makes reference to the classic "two word" formulation of
closures, building the expectation that that's what you're going to
propose--but it isn't. The New Implementation section could
explicitly dismiss it briefly.
Feel free to ignore both of these comments if you don't intend the doc
to stick around after you've finished the work, but I hope that's not
the case, as it's a lucid explanation of and motivation for the new
(and soon to be current) implementation.
cheers
alan
Brad points out that this belongs in Russ's other thread about
functions---sorry for the noise.
--
---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Continue reading on narkive:
Loading...