code review 6736071: spec: clarify returns, defer statements, and panics

spec: clarify returns, defer statements, and panics

This is an attempt at making the interaction between
these three constructs clearer. Specifically:

- return statements terminate a function, execute deferred
  functions, return to the caller, and then execution
  continues after the call

- panic calls terminate a function, execute deferred
  functions, return to the caller, and then re-panic

- deferred functions are executed before a function _returns_
  to its caller

The hope is that with this change it becomes clear when a
deferred function is executed (when a function returns),
and when it is not (when a program exits).

[gri, 2012-10-23 22:40:57]

Hello r@golang.org, rsc@golang.org, iant@golang.org, ken@golang.org (cc:
golang-dev@googlegroups.com),

I'd like you to review this change to
https://code.google.com/p/go

[iant, 2012-10-23 23:14:58]

https://codereview.appspot.com/6736071/diff/4001/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/6736071/diff/4001/doc/go_spec.html#newcode4547
doc/go_spec.html:4547: continues with the statement immediately following the
call of <code>F</code>.
Execution continues in a more complex way, because a function call may occur in
the middle of an expression.  It might be simpler to omit the final clause
starting with "where execution."  I'm not sure offhand how to write it
correctly.

https://codereview.appspot.com/6736071/diff/4001/doc/go_spec.html#newcode4617
doc/go_spec.html:4617: Regardless of how they are declared, all the result
values are initialized to the zero values for their type (§<a
href="#The_zero_value">The zero value</a>) upon entry to the function, and they
are set by the "return" statement before deferred functions are executed, if
any.
Not that it matters, but this line is quite long.

I think I would put the new subordinate clause in a different sentence.  And
maybe make it conditional, as in "A return statement that returns any values
sets the result parameters before any deferred functions are executed."

https://codereview.appspot.com/6736071/diff/4001/doc/go_spec.html#newcode4746
doc/go_spec.html:4746: function returns, either because the surrrounding
function executed a <a href="#Return_statements">return statement</a>,
s/rrr/rr/

[gri, 2012-10-23 23:31:15]

PTAL.

https://codereview.appspot.com/6736071/diff/4001/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/6736071/diff/4001/doc/go_spec.html#newcode4547
doc/go_spec.html:4547: continues with the statement immediately following the
call of <code>F</code>.
On 2012/10/23 23:14:58, iant wrote:
> Execution continues in a more complex way, because a function call may occur
in
> the middle of an expression.  It might be simpler to omit the final clause
> starting with "where execution."  I'm not sure offhand how to write it
> correctly.

Done.

https://codereview.appspot.com/6736071/diff/4001/doc/go_spec.html#newcode4617
doc/go_spec.html:4617: Regardless of how they are declared, all the result
values are initialized to the zero values for their type (§<a
href="#The_zero_value">The zero value</a>) upon entry to the function, and they
are set by the "return" statement before deferred functions are executed, if
any.
On 2012/10/23 23:14:58, iant wrote:
> Not that it matters, but this line is quite long.
> 
> I think I would put the new subordinate clause in a different sentence.  And
> maybe make it conditional, as in "A return statement that returns any values
> sets the result parameters before any deferred functions are executed."

Weird. Not sure how this happened. Fixed.

https://codereview.appspot.com/6736071/diff/4001/doc/go_spec.html#newcode4746
doc/go_spec.html:4746: function returns, either because the surrrounding
function executed a <a href="#Return_statements">return statement</a>,
On 2012/10/23 23:14:58, iant wrote:
> s/rrr/rr/

Done.

[iant2, 2012-10-23 23:38:15]

On Tue, Oct 23, 2012 at 4:31 PM,  <gri@golang.org> wrote:
>
>
> https://codereview.appspot.com/6736071/diff/4001/doc/go_spec.html#newcode4617
> doc/go_spec.html:4617: Regardless of how they are declared, all the
> result values are initialized to the zero values for their type (§<a
> href="#The_zero_value">The zero value</a>) upon entry to the function,
> and they are set by the "return" statement before deferred functions are
> executed, if any.
> On 2012/10/23 23:14:58, iant wrote:
>>
>> Not that it matters, but this line is quite long.
>
>
>> I think I would put the new subordinate clause in a different
>
> sentence.  And
>>
>> maybe make it conditional, as in "A return statement that returns any
>
> values
>>
>> sets the result parameters before any deferred functions are
>
> executed."
>
> Weird. Not sure how this happened. Fixed.

I think you did the first part (long line) but not the second.

Ian

[gri, 2012-10-23 23:52:34]

Thanks. Done.
PTAL.
- gri


On Tue, Oct 23, 2012 at 4:38 PM, Ian Lance Taylor <iant@google.com> wrote:

> On Tue, Oct 23, 2012 at 4:31 PM,  <gri@golang.org> wrote:
> >
> >
> >
> https://codereview.appspot.com/6736071/diff/4001/doc/go_spec.html#newcode4617
> > doc/go_spec.html:4617: Regardless of how they are declared, all the
> > result values are initialized to the zero values for their type (§<a
> > href="#The_zero_value">The zero value</a>) upon entry to the function,
> > and they are set by the "return" statement before deferred functions are
> > executed, if any.
> > On 2012/10/23 23:14:58, iant wrote:
> >>
> >> Not that it matters, but this line is quite long.
> >
> >
> >> I think I would put the new subordinate clause in a different
> >
> > sentence.  And
> >>
> >> maybe make it conditional, as in "A return statement that returns any
> >
> > values
> >>
> >> sets the result parameters before any deferred functions are
> >
> > executed."
> >
> > Weird. Not sure how this happened. Fixed.
>
> I think you did the first part (long line) but not the second.
>
> Ian
>

[iant, 2012-10-24 00:08:26]

LGTM

https://codereview.appspot.com/6736071/diff/16001/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/6736071/diff/16001/doc/go_spec.html#newcode4618
doc/go_spec.html:4618: function. A "return" statement that specifies results
sets the result parameters before
Link to Return_statements section.

[gri, 2012-10-24 00:10:52]

https://codereview.appspot.com/6736071/diff/16001/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/6736071/diff/16001/doc/go_spec.html#newcode4618
doc/go_spec.html:4618: function. A "return" statement that specifies results
sets the result parameters before
On 2012/10/24 00:08:26, iant wrote:
> Link to Return_statements section.

We _are_ in the return statements section.

[r, 2012-10-26 16:28:39]

LGTM

[rsc, 2012-11-01 16:25:42]

LGTM

[gri, 2012-11-01 17:13:50]

*** Submitted as http://code.google.com/p/go/source/detail?r=632ca9d98436 ***

spec: clarify returns, defer statements, and panics

This is an attempt at making the interaction between
these three constructs clearer. Specifically:

- return statements terminate a function, execute deferred
  functions, return to the caller, and then execution
  continues after the call

- panic calls terminate a function, execute deferred
  functions, return to the caller, and then re-panic

- deferred functions are executed before a function _returns_
  to its caller

The hope is that with this change it becomes clear when a
deferred function is executed (when a function returns),
and when it is not (when a program exits).

R=r, rsc, iant, ken, iant
CC=golang-dev
http://codereview.appspot.com/6736071