qbit/go
1
0
Fork 0
mirror of https://github.com/golang/go synced 2024-11-21 18:44:45 -07:00
Code Releases Activity

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

Browse Source 
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
This commit is contained in:
Robert Griesemer 2010-07-29 18:13:41 -07:00
parent bab711b184
commit 07cc6440dc
2 changed files with 6 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
doc/go_spec.html
View File

@ -1,5 +1,5 @@
<!-- 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.
<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:
<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>

4
test/parentype.go
View File

@ -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)));
} }