From a36b5b99cca834aa4968d7aaa81f5e5565f7c461 Mon Sep 17 00:00:00 2001 From: Robert Griesemer Date: Thu, 27 Feb 2014 08:57:30 -0800 Subject: [PATCH] spec: slightly rephrased wording on parsing ambiguity for composite literals Fixes #4482. LGTM=r R=r, iant, rsc, ken CC=golang-codereviews https://golang.org/cl/69020045 --- doc/go_spec.html | 18 ++++++++---------- 1 file changed, 8 insertions(+), 10 deletions(-) diff --git a/doc/go_spec.html b/doc/go_spec.html index 11b7225719..59b30739c6 100644 --- a/doc/go_spec.html +++ b/doc/go_spec.html @@ -1,6 +1,6 @@ @@ -2267,8 +2267,6 @@ Similarly, elements that are addresses of composite literals may elide the &T when the element type is *T.

- - 
 [...]Point{{1.5, -3.5}, {0, 0}}   // same as [...]Point{Point{1.5, -3.5}, Point{0, 0}}
 [][]int{{1, 2, 3}, {4, 5}}        // same as [][]int{[]int{1, 2, 3}, []int{4, 5}}
@@ -2278,13 +2276,13 @@ the &T when the element type is *T.
 
 

 A parsing ambiguity arises when a composite literal using the
-TypeName form of the LiteralType appears between the
-keyword and the opening brace of the block of an
-"if", "for", or "switch" statement, because the braces surrounding
-the expressions in the literal are confused with those introducing
-the block of statements. To resolve the ambiguity in this rare case,
-the composite literal must appear within
-parentheses.
+TypeName form of the LiteralType appears as an operand between the
+keyword and the opening brace of the block
+of an "if", "for", or "switch" statement, and the composite literal
+is not enclosed in parentheses, square brackets, or curly braces.
+In this rare case, the opening brace of the literal is erroneously parsed
+as the one introducing the block of statements. To resolve the ambiguity,
+the composite literal must appear within parentheses.
 

 
 
-- 
2.52.0