Commit 07cc6440 authored by Robert Griesemer's avatar Robert Griesemer

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
https://golang.org/cl/1913041
parent bab711b1
<!-- title The Go Programming Language Specification --> <!-- title The Go Programming Language Specification -->
<!-- subtitle Version of July 14, 2010 --> <!-- subtitle Version of July 29, 2010 -->
<!-- <!--
TODO TODO
...@@ -1974,7 +1974,7 @@ a single expression or a key-value pair. ...@@ -1974,7 +1974,7 @@ a single expression or a key-value pair.
<pre class="ebnf"> <pre class="ebnf">
CompositeLit = LiteralType "{" [ ElementList [ "," ] ] "}" . CompositeLit = LiteralType "{" [ ElementList [ "," ] ] "}" .
LiteralType = StructType | ArrayType | "[" "..." "]" ElementType | LiteralType = StructType | ArrayType | "[" "..." "]" ElementType |
SliceType | MapType | TypeName | "(" LiteralType ")" . SliceType | MapType | TypeName .
ElementList = Element { "," Element } . ElementList = Element { "," Element } .
Element = [ Key ":" ] Value . Element = [ Key ":" ] Value .
Key = FieldName | ElementIndex . Key = FieldName | ElementIndex .
...@@ -2096,10 +2096,11 @@ and is a shortcut for a slice operation applied to an array literal: ...@@ -2096,10 +2096,11 @@ and is a shortcut for a slice operation applied to an array literal:
<p> <p>
A parsing ambiguity arises when a composite literal using the A parsing ambiguity arises when a composite literal using the
TypeName form of the LiteralType appears in the condition of an TypeName form of the LiteralType appears between the
<a href="#Keywords">keyword</a> and the opening brace of the block of an
"if", "for", or "switch" statement, because the braces surrounding "if", "for", or "switch" statement, because the braces surrounding
the expressions in the literal are confused with those introducing the expressions in the literal are confused with those introducing
a block of statements. To resolve the ambiguity in this rare case, the block of statements. To resolve the ambiguity in this rare case,
the composite literal must appear within the composite literal must appear within
parentheses. parentheses.
</p> </p>
......
...@@ -11,9 +11,7 @@ func g() {} ...@@ -11,9 +11,7 @@ func g() {}
func main() { func main() {
f(map[string]string{"a":"b","c":"d"}); f(map[string]string{"a":"b","c":"d"});
f([...]int{1,2,3}); f([...]int{1,2,3});
f(([...]int){1,2,3}); f(map[string]func(){"a":g,"c":g});
f((map[string]string){"a":"b","c":"d"});
f((map[string]func()){"a":g,"c":g});
f(make(chan(<-chan int))); f(make(chan(<-chan int)));
f(make(chan<-(chan int))); f(make(chan<-(chan int)));
} }
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment