code review 160570043: spec: permit parentheses around builtin function names

spec: permit parentheses around builtin function names

Not a language change.

This is simply documenting the status quo which permits
builtin function names to be parenthesized in calls; e.g.,
both

        len(s)
and
        (((len)))(s)

are accepted by all compilers and go/types.

Changed the grammar by merging the details of BuiltinCall
with ordinary Calls. Also renamed the Call production to
Arguments which more clearly identifies that part of the
grammar and also matches better with its counterpart on
the declaration side (Parameters).

The fact that the first argument can be a type (for builtins)
or cannot be a type (for regular function calls) is expressed
in the prose, no need to make the grammar more complicated.

Fixes issue 9001.

[gri, 2014-10-27 21:35:23]

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/

[iant, 2014-10-27 22:12:01]

LGTM

[r, 2014-10-27 22:47:43]

LGTM

[rsc, 2014-10-27 22:51:47]

LGTM

[dave_cheney.net, 2014-10-27 22:53:31]

Curiously gofmt is able to remove some, but not all of the parenthesis
in the expression (((len)))(s). http://play.golang.org/p/FMYIzZxkeE

On Tue, Oct 28, 2014 at 9:51 AM,  <rsc@golang.org> wrote:
> LGTM
>
>
> https://codereview.appspot.com/160570043/
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-codereviews" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-codereviews+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[gri, 2014-10-27 23:29:11]

Yes, it's not smart enough - it just the easy ones where no precedence or
further context info is needed for now. Something for later.
- gri

On Mon, Oct 27, 2014 at 3:53 PM, Dave Cheney <dave@cheney.net> wrote:

> Curiously gofmt is able to remove some, but not all of the parenthesis
> in the expression (((len)))(s). http://play.golang.org/p/FMYIzZxkeE
>
> On Tue, Oct 28, 2014 at 9:51 AM,  <rsc@golang.org> wrote:
> > LGTM
> >
> >
> > https://codereview.appspot.com/160570043/
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "golang-codereviews" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to golang-codereviews+unsubscribe@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>

[gri, 2014-10-27 23:31:17]

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

spec: permit parentheses around builtin function names

Not a language change.

This is simply documenting the status quo which permits
builtin function names to be parenthesized in calls; e.g.,
both

        len(s)
and
        (((len)))(s)

are accepted by all compilers and go/types.

Changed the grammar by merging the details of BuiltinCall
with ordinary Calls. Also renamed the Call production to
Arguments which more clearly identifies that part of the
grammar and also matches better with its counterpart on
the declaration side (Parameters).

The fact that the first argument can be a type (for builtins)
or cannot be a type (for regular function calls) is expressed
in the prose, no need to make the grammar more complicated.

Fixes issue 9001.

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

[gobot, 2014-10-27 23:49:14]

This CL appears to have broken the linux-amd64-race builder.
See http://build.golang.org/log/c18793d061ebdbe0fe646ea5a4d9cf6e39207487