code review 66860046: spec: clarify what is considered a function call for le...

spec: clarify what is considered a function call for len/cap special case

gccgo considers built-in function calls returning a constant not as function call (issue 7386)
go/types considers any call (regular or built-in) as a function call

The wording and examples clarify that only "function calls" that are issued
at run-time (and thus do not result in a constant result) are considered
function calls in this case.

gc is inconsistent (issue 7385)
gccgo already interprets the spec accordingly and issue 7386 is moot.
go/types considers all calls (constant or not) as function calls (issue 7457).

Fixes issue 7387.
Fixes issue 7386.

[gri, 2014-02-22 00:08:39]

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

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

[r, 2014-02-22 00:11:48]

LGTM but of course wait for others

https://codereview.appspot.com/66860046/diff/40001/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/66860046/diff/40001/doc/go_spec.html#newcode3
doc/go_spec.html:3: "Subtitle": "Version of Feb 21, 2014",
can it really have been this long? :=)

[iant, 2014-02-24 05:52:26]

The gccgo behaviour seems correct to me.

But I'm OK with this change.  It's not like it affects any real programs.

[rsc, 2014-03-04 01:07:30]

It seems a bit confusing to me that an expression can be both a function call
and a constant. At the least, there should be an example of this, like 

const (
    c1 = imag(2i) // valid: imag(2i) = 2.0 is a constant
    c2 = len([10]float64{2}) // valid: [10]float64{2} contains no function calls
    c3 = len([10]float64{imag(2i)}) // invalid: imag(2i) is a constant but also
a function call
    c4 = len([10]float64{c1}) // valid: c1 is not a function call even though it
is initialized using one
)

The distinction between c3 and c4 in particular is quite surprising. My
understanding is that gc and gccgo accept all these, including c3.

I think it would probably be much easier to adopt the gc/gccgo interpretation
instead, namely that constant expressions are not function calls for the
purposes of this rule.

Issue 7385 does point out a real bug in gc (case 5), but I think that is
orthogonal to the rest of this discussion.

[gri, 2014-03-04 01:19:13]

I'm fine with the gccgo interpretation, and you're example (c3 vs c4) is
compelling.

I'll rephrase this.

[gri, 2014-03-04 01:49:23]

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

Please take another look.

[rsc, 2014-03-04 02:00:39]

LGTM but wait for r, iant

[r, 2014-03-04 02:19:23]

LGTM

[iant, 2014-03-04 02:33:57]

LGTM

In CL description, s/mute/moot/.

[r, 2014-03-04 02:41:25]

Don't point that moot at me, Moriarty.

[gri, 2014-03-04 04:07:36]

*** Submitted as https://code.google.com/p/go/source/detail?r=2b66d388d1af ***

spec: clarify what is considered a function call for len/cap special case

gccgo considers built-in function calls returning a constant not as function
call (issue 7386)
go/types considers any call (regular or built-in) as a function call

The wording and examples clarify that only "function calls" that are issued
at run-time (and thus do not result in a constant result) are considered
function calls in this case.

gc is inconsistent (issue 7385)
gccgo already interprets the spec accordingly and issue 7386 is moot.
go/types considers all calls (constant or not) as function calls (issue 7457).

Fixes issue 7387.
Fixes issue 7386.

LGTM=r, rsc, iant
R=r, rsc, iant, ken
CC=golang-codereviews
https://codereview.appspot.com/66860046

[gobot, 2014-03-04 04:40:41]

This CL appears to have broken the darwin-amd64-race-cheney builder.