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 957618d5ee5f2de870a6aa561943521840606491..c1f68a0ce6b6e07dcd9c1cd32c2cd4252122708c 100644 (file)
--- 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>