code review 6498138: spec: clarify expression statements

spec: clarify expression statements

Function and method calls are valid expression statements,
but calling certain built-in functions is not permitted.
Enumerate the built-ins.

Also: unsafe.Offsetof permits parenthesized selectors as
arguments.

This is simply documenting existing compiler behavior
(both gc and gccgo agree).

[gri, 2012-09-17 21:15:30]

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

[gri, 2012-09-17 21:19:37]

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

Please take another look.

[r, 2012-09-17 21:19:38]

http://codereview.appspot.com/6498138/diff/5001/doc/go_spec.html
File doc/go_spec.html (right):

http://codereview.appspot.com/6498138/diff/5001/doc/go_spec.html#newcode3803
doc/go_spec.html:3803: and <a href="#Receive_operator">receive operations</a>
order here is in out in. better to go in in out or out in in. plus no parens.

Except for calls of <a href="#Built-in_functions">built-in functions</a>.
function and method <a href="#Calls">calls</a> and <a href="#Receive_operator">
receive operations</a> may appear in statement context.

http://codereview.appspot.com/6498138/diff/5001/doc/go_spec.html#newcode4818
doc/go_spec.html:4818: functions), or <a href="#Receive_operator">receive
operations</a>; in this
"does not contain ... excluding" is hard to parse, plus the rewrite above would
help. no parens.

[gri, 2012-09-17 21:35:24]

PTAL.
- gri

http://codereview.appspot.com/6498138/diff/5001/doc/go_spec.html
File doc/go_spec.html (right):

http://codereview.appspot.com/6498138/diff/5001/doc/go_spec.html#newcode3803
doc/go_spec.html:3803: and <a href="#Receive_operator">receive operations</a>
On 2012/09/17 21:19:38, r wrote:
> order here is in out in. better to go in in out or out in in. plus no parens.
> 
> Except for calls of <a href="#Built-in_functions">built-in functions</a>.
> function and method <a href="#Calls">calls</a> and <a
href="#Receive_operator">
> receive operations</a> may appear in statement context.
> 

Done.

http://codereview.appspot.com/6498138/diff/5001/doc/go_spec.html#newcode4818
doc/go_spec.html:4818: functions), or <a href="#Receive_operator">receive
operations</a>; in this
On 2012/09/17 21:19:38, r wrote:
> "does not contain ... excluding" is hard to parse, plus the rewrite above
would
> help. no parens.

Done.

[iant, 2012-09-17 21:55:24]

https://codereview.appspot.com/6498138/diff/5003/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/6498138/diff/5003/doc/go_spec.html#newcode4817
doc/go_spec.html:4817: 
Odd place for a blank line.

https://codereview.appspot.com/6498138/diff/5003/doc/go_spec.html#newcode4818
doc/go_spec.html:4818: and the expression <code>s</code>, except for calls of <a
href="#Built-in_functions">built-in functions</a>,
This does not sound right.  If we do not ignore calls in general, we should not
ignore calls to copy or append.  Or recover.

https://codereview.appspot.com/6498138/diff/5003/doc/go_spec.html#newcode4827
doc/go_spec.html:4827: and the expression <code>s</code> does not contain
Did you mean to delete this?

[gri, 2012-09-17 22:05:26]

PTAL

https://codereview.appspot.com/6498138/diff/5003/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/6498138/diff/5003/doc/go_spec.html#newcode4817
doc/go_spec.html:4817: 
On 2012/09/17 21:55:24, iant wrote:
> Odd place for a blank line.

Done.

https://codereview.appspot.com/6498138/diff/5003/doc/go_spec.html#newcode4818
doc/go_spec.html:4818: and the expression <code>s</code>, except for calls of <a
href="#Built-in_functions">built-in functions</a>,
On 2012/09/17 21:55:24, iant wrote:
> This does not sound right.  If we do not ignore calls in general, we should
not
> ignore calls to copy or append.  Or recover.

Interesting. This appears to be implemented in a built-in function specific way.
Looks like it's more like a compiler error and we shouldn't have this
restriction in the first place.

https://codereview.appspot.com/6498138/diff/5003/doc/go_spec.html#newcode4827
doc/go_spec.html:4827: and the expression <code>s</code> does not contain
On 2012/09/17 21:55:24, iant wrote:
> Did you mean to delete this?

Done.

[r, 2012-09-17 22:39:05]

CL description needs refinement

[r, 2012-09-17 22:40:43]

LGTM
make an issue for later consideration to clean this up, maybe in the TODO list
at the top

[gri, 2012-09-17 22:43:55]

On 2012/09/17 22:39:05, r wrote:
> CL description needs refinement

PTAL.

[gri, 2012-09-18 16:52:41]

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

Please take another look.

[iant, 2012-09-18 16:57:08]

LGTM

https://codereview.appspot.com/6498138/diff/17001/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/6498138/diff/17001/doc/go_spec.html#newcode3815
doc/go_spec.html:3815: append cap complex imag len make new real
For the record, gccgo currently also rejects unsafe.Alignof, unsafe.Sizeof, and
unsafe.Offsetof in statement context.

[gri, 2012-09-18 17:19:39]

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

Please take another look.

[iant, 2012-09-18 17:30:01]

LGTM

[r, 2012-09-18 17:32:39]

LGTM

[rsc, 2012-09-18 18:24:32]

LGTM

[gri, 2012-09-18 18:26:01]

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

spec: clarify expression statements

Function and method calls are valid expression statements,
but calling certain built-in functions is not permitted.
Enumerate the built-ins.

Also: unsafe.Offsetof permits parenthesized selectors as
arguments.

This is simply documenting existing compiler behavior
(both gc and gccgo agree).

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