From: Russ Cox <rsc@golang.org>
Date: Tue, 3 Mar 2009 23:40:30 +0000 (-0800)
Subject: The final piece of the alternative to my parens proposal
X-Git-Tag: weekly.2009-11-06~2120
X-Git-Url: http://www.git.cypherpunks.su/?a=commitdiff_plain;h=7a5e97ba915bddfcaf018280364b1690d4c88846;p=gostls13.git

The final piece of the alternative to my parens proposal
(i.e., the status quo with braces in composite literals).

DELTA=20  (16 added, 0 deleted, 4 changed)
OCL=25640
CL=25646
---

diff --git a/doc/go_spec.html b/doc/go_spec.html
index 957618d5ee..c1f68a0ce6 100644
--- a/doc/go_spec.html
+++ b/doc/go_spec.html
@@ -1875,10 +1875,11 @@ ExprPair      = Expression ":" Expression .
 
 <p>
 The LiteralType must be a struct, array, slice, or map type.
-<font color=red>TODO: then why doesn't the grammar say that?</font>
-The types of the expressions must match the respective field, element, and
-key types of the LiteralType; there is no automatic type conversion.
-Given
+(The grammar enforces this constraint except when the type is given
+as a TypeName.)
+The types of the expressions must be assignment compatible to
+the respective field, element, and key types of the LiteralType;
+there is no additional conversion.
 </p>
 
 <pre>
@@ -1936,6 +1937,21 @@ key-value pairs separated by a colon:
 m := map[string]int{"good": 0, "bad": 1, "indifferent": 7};
 </pre>
 
+<p>
+A parsing ambiguity arises when a composite literal using the
+TypeName form of the LiteralType appears in the condition of an
+"if", "for", or "switch" statement, because the braces surrounding
+the expressions in the literal are confused with those introducing
+a block of statements. To resolve the ambiguity in this rare case,
+the composite literal must appear within
+parentheses.
+</p>
+
+<pre>
+if x == (T{a,b,c}[i]) { ... }
+if (x == T{a,b,c}[i]) { ... }
+</pre>
+
 <h3>Function literals</h3>
 
 <p>