code review 6441102: spec: clarify evaluation order

doc/go_spec.html

 <!--{
         "Title": "The Go Programming Language Specification",
-        "Subtitle": "Version of August 3, 2012",
+        "Subtitle": "Version of August 9, 2012",
         "Path": "/ref/spec"
 }-->
 
 <!--
 TODO
 [ ] need language about function/method calls and parameter passing rules
 [ ] last paragraph of #Assignments (constant promotion) should be elsewhere
     and mention assignment to empty interface.
 [ ] need to say something about "scope" of selectors?
 [ ] clarify what a field name is in struct declarations
@@ skipping 2075 matching lines @@
 Value         = Expression | LiteralValue .
 </pre>
 
 <p>
 The LiteralType must be a struct, array, slice, or map type
 (the grammar enforces this constraint except when the type is given
 as a TypeName).
 The types of the expressions must be <a href="#Assignability">assignable</a>
 to the respective field, element, and key types of the LiteralType;
 there is no additional conversion.
-The expressions in the element list are
-<a href="#Order_of_evaluation">evaluated in the usual order</a>.
 The key is interpreted as a field name for struct literals,
 an index expression for array and slice literals, and a key for map literals.
 For map literals, all elements must have a key. It is an error
 to specify multiple elements with the same field name or
 constant key value.
 </p>
 
 <p>
 For struct literals the following rules apply:
 </p>
@@ skipping 1578 matching lines @@
 TODO: perhaps ^ should be disallowed on non-uints instead of assuming twos complement.
 Also it may be possible to make typed constants more like variables, at the cost of fewer
 overflow etc. errors being caught.
 </span>
 </p>
 -->
 
 <h3 id="Order_of_evaluation">Order of evaluation</h3>
 
 <p>
-Unless specified otherwise, when evaluating the <a href="#Operands">operands</a>

[iant, 2012/08/03 22:07:44]

You no longer mention assignments here, but we do want to specify that the
relevant expressions on the LHS of an assignment are evaluated before the ones
on the RHS.

-in an <a href="#Operators">expression</a>, expression list,
-or a <a href="#Composite_literals">composite literals</a> element list,
-all function calls, method calls and
-communication operations are evaluated in lexical left-to-right order.
+When evaluating the <a href="#Operands">operands</a> of an expression,
+<a href="#Assignments">assignment</a>, or
+<a href="#Return_statements">return statement</a>,
+all function calls, method calls, and
+communication operations are evaluated in lexical left-to-right
+order.
 </p>
 
 <p>
 For example, in the assignment
 </p>
 <pre>
 y[f()], ok = g(h(), i()+x[j()], &lt;-c), k()
 </pre>
 <p>
 the function calls and communication happen in the order
 <code>f()</code>, <code>h()</code>, <code>i()</code>, <code>j()</code>,
 <code>&lt;-c</code>, <code>g()</code>, and <code>k()</code>.
 However, the order of those events compared to the evaluation
 and indexing of <code>x</code> and the evaluation
 of <code>y</code> is not specified.
 </p>
 
 <pre>
 a := 1
 f := func() int { a = 2; return 3 }
-x := []int{a, f()}  // x may be [1, 3] or [2, 3]
+x := []int{a, f()}  // x may be [1, 3] or [2, 3]: evaluation order between a and f() is not specified
 </pre>
 
 <p>
 Floating-point operations within a single expression are evaluated according to
 the associativity of the operators.  Explicit parentheses affect the evaluation
 by overriding the default associativity.
 In the expression <code>x + (y + z)</code> the addition <code>y + z</code>
 is performed before adding <code>x</code>.
 </p>
 
@@ skipping 758 matching lines @@
 <p>
 There are three ways to return values from a function with a result
 type:
 </p>
 
 <ol>
         <li>The return value or values may be explicitly listed
                 in the "return" statement. Each expression must be single-valued
                 and <a href="#Assignability">assignable</a>
                 to the corresponding element of the function's result type.
-                The expressions are <a href="#Order_of_evaluation">evaluated in the usual order</a>.
 <pre>
 func simpleF() int {
         return 2
 }
 
 func complexF1() (re float64, im float64) {
         return -7.0, -4.0
 }
 </pre>
         </li>
@@ skipping 1017 matching lines @@
 </li>
 
 <li>For a variable <code>x</code> of array type: <code>unsafe.Alignof(x)</code> is the same as
    <code>unsafe.Alignof(x[0])</code>, but at least 1.
 </li>
 </ol>
 
 <p>
 A struct or array type has size zero if it contains no fields (or elements, respectively) that have a size greater than zero. Two distinct zero-size variables may have the same address in memory.
 </p>