NoNo for Associativity of Assignments?

[Joel C. Salomon]

Manfred Nowak wrote:
> Now that the associativity of comparisons has been dropped, I have
> the heart to point the readers attention to the associativity of
> assignments: 
> 
>   There is no evaluation order specified for assignments.
> 
> From the specs:
> | The right operand is implicitly converted to the type of the left
> | operand, and assigned to it. The result type is the type of the
> | lvalue, and the result value is the value of the lvalue after the
> | assignment. 
> | The left operand must be an lvalue. 
> 
> and
> 
> | It is an error to depend on order of evaluation when it is not
> | specified. 
> 
> 
> This means: "a = b = c;" is an error unless "a == b" and "b == c"!

To my mind this means that in the expression
	a[f()] = b[g()] = h[()]
it is unspecified in which order f, g, and h are called; specifically, 
a[f()] may be evaluated to an lvalue before either of g or h is called, 
or after both, or “something else” and it’s an error to care.  Not sure 
where the ambiguity you’re claiming in
	a = b = c
can arise.

> Canonical solutions for this dilemma:
> - drop associativity

Bad idea; unlike the semantics for the comparison operators, the meaning 
of chained assignments is unambiguous to compiler and programmer alike.

> - specify evaluation order

Again, why does it matter if the lvalue-expression is obtained before or 
after the rvalue expression?  The grammar removes any ambiguity.

--Joel