code review 1913041: go_spec: don't allow parens around the literal type of ...

go_spec: don't allow parens around the literal type of composite literals

Background: The current spec is imprecise with respect to the parsing ambiguity
for composite literals: It says that the ambiguity arises when the TypeName form
of the LiteralType is used. The following code:

    if (B) {} ...

is not using the TypeName form (but the parenthesized TypeName form) and thus
could be interpreted as:

    if ((B){}) ...

instead of

    if B {} ...

Both compilers and gofmt choose the latter interpretation. One could fix the
spec by making the clause regarding the parsing ambiguity more precise ("...using
the _possibly parenthesized_ TypeName form of the LiteralType..."). The alternative
(chosen here) is to simply disallow parenthesized literal types. Except for a single
test case (test/parentype.go) there appears to be no Go code under $GOROOT containing
parenthesized literal types. Furthermore, parentheses are never needed around a
literal type for correct parsing.

[gri, 2010-07-29 21:59:41]

Hello golang-dev@googlegroups.com,

I'd like you to review this change.

[r2, 2010-07-29 22:05:46]

LGTM

but let the compiler owners weigh in

[rsc1, 2010-07-30 00:54:44]

LGTM

simplifies the grammar in the spec.
a little more complex in 6g but no
more than needing to toss parens
in the other case.

[gri, 2010-07-30 01:13:44]

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

go_spec: don't allow parens around the literal type of composite literals

Background: The current spec is imprecise with respect to the parsing ambiguity
for composite literals: It says that the ambiguity arises when the TypeName form
of the LiteralType is used. The following code:

    if (B) {} ...

is not using the TypeName form (but the parenthesized TypeName form) and thus
could be interpreted as:

    if ((B){}) ...

instead of

    if B {} ...

Both compilers and gofmt choose the latter interpretation. One could fix the
spec by making the clause regarding the parsing ambiguity more precise
("...using
the _possibly parenthesized_ TypeName form of the LiteralType..."). The
alternative
(chosen here) is to simply disallow parenthesized literal types. Except for a
single
test case (test/parentype.go) there appears to be no Go code under $GOROOT
containing
parenthesized literal types. Furthermore, parentheses are never needed around a
literal type for correct parsing.

R=golang-dev
CC=golang-dev
http://codereview.appspot.com/1913041