In article Ipy@cix.compulink.co.uk, mwoolf@cix.compulink.co.uk ("Matthew Woolf") writes:
>Surely (i?j:k)=5 is legal becuase both i and j are reference types
>(L-values), so the result of the expression is a reference type. It
>occurs to me the the really question here is what is the relationship
>between the return type and conditional expression types following the ?.
>
>The MSVC compiler accepts (i?j:k)=5 as above with or without the
>parenthesis.

The ARM did not make clear how to parse the expression
 i ? j : k = 5
It depends on what kind of expression can follow the colon. In C, the
colon cannot be followed by an assignment expression, so it would
be parsed as
 (i ? j : k) = 5
which is an error (in C). You would have to write
 i ? j : (k = 5)
if that is what you mean.

C++ originally used the same grammar rule for conditional expressions.
The C++ Committee voted some time ago to change the grammar to allow
assignment expressions after the colon, so that
 i ? j : k = 5
is now to be interpreted as
 i ? j : (k = 5)

As a matter of style, adding the parens makes it clear to human readers
what you intend, and ensures that the compiler interprets it that way too.

This is not to be taken lightly. In C++, you can also write
 ( i ? j : k ) = 5
which will assign 5 to either j or k, if both are modifiable lvalues of
compatible types. For a while (and maybe still) there were compilers
which used both the C grammar rule and the C++ rule allowing a conditional
expression to be an lvalue. You could thus potentially get two different
results from two different compilers which were written to different
language specifications.

---
Steve Clamage, stephen.clamage@eng.sun.com

Thanks for responding.  I agree with you except for one quibble:

> The ARM did not make clear how to parse the expression
>         i ? j : k = 5
> It depends on what kind of expression can follow the colon. In C, the
> colon cannot be followed by an assignment expression, so it would
> be parsed as
>         (i ? j : k) = 5
> ...

I think that in the ARM and in ANSI/ISO C
         i ? j : k = 5
cannot be parsed at all, because 'i ? j : k' is not a <unary-expression>
as required by <assignment-expression>.  And, as you point out, 'k = 5' is
not a <conditional-expression> so the parse can't be 'i ? j : (k = 5)'
either.

> C++ originally used the same grammar rule for conditional expressions.
> The C++ Committee voted some time ago to change the grammar to allow
> assignment expressions after the colon, so that
>         i ? j : k = 5
> is now to be interpreted as
>         i ? j : (k = 5)

Did the Committee think this was particularly useful?  It makes a
straight-forward precedence table hard to produce, in
         i ? j : k = 5     // parsed as:  i ? j : (k = 5)
the '=' has higher precedence, but in the similar
         x = i ? j : k     // parsed as:  x = (i ? j : k)
the '?:' has higher precedence.

The fact that Cfront, gcc and the examples in the ARM expect the parse to
be '(i ? j : k) = 5' indicates that perhaps the Committee mis-fixed the
grammar.

> As a matter of style, adding the parens makes it clear to human readers
> what you intend, and ensures that the compiler interprets it that way too.

Given the confusion, I agree.  But I had taken i ? j : k = 5 as a new,
soon to be well-known, idiom much the same way as *p++ is an idiom.
       --scott

In article <sdouglass-0612941304330001@193.131.176.202>,
sdouglass@armltd.co.uk (scott douglass) wrote:

> > assignment expressions after the colon, so that
> >         i ? j : k = 5
> > is now to be interpreted as
> >         i ? j : (k = 5)
>
> Did the Committee think this was particularly useful?  It makes a
> straight-forward precedence table hard to produce, in
>          i ? j : k = 5     // parsed as:  i ? j : (k = 5)
> the '=' has higher precedence, but in the similar
>          x = i ? j : k     // parsed as:  x = (i ? j : k)
> the '?:' has higher precedence.
>
> The fact that Cfront, gcc and the examples in the ARM expect the parse to
> be '(i ? j : k) = 5' indicates that perhaps the Committee mis-fixed the
> grammar.

I've forgotten the reasons why this was considered a useful enhancement.
It was probably in order to support
        i ? j = 4 : k = 5
At the time of adoption, it had been implemented as an extension in the
Metaware C compiler.

Yes, a straight-forward precedence table is impossible to produce for
this grammar feature.  However, there is a fairly easy generalization
of precedence in which an operator can have one precedence on the left
side and a different one on the right side, which will handle it.  I made
sure of this at the time because the compiler I was developing uses
precedence to parse expressions.
--
Scott Turner
Liant Software Corp., Framingham, Massachusetts, USA
pkt@lpi.liant.com

In article <sdouglass-0612941304330001@193.131.176.202>, sdouglass@armltd.co.uk (scott douglass) writes:
>...
>> C++ originally used the same grammar rule for conditional expressions.
>> The C++ Committee voted some time ago to change the grammar to allow
>> assignment expressions after the colon, so that
>>         i ? j : k = 5
>> is now to be interpreted as
>>         i ? j : (k = 5)
>
>Did the Committee think this was particularly useful?  It makes a
>straight-forward precedence table hard to produce, in
>         i ? j : k = 5     // parsed as:  i ? j : (k = 5)
>the '=' has higher precedence, but in the similar
>         x = i ? j : k     // parsed as:  x = (i ? j : k)
>the '?:' has higher precedence.
>
>The fact that Cfront, gcc and the examples in the ARM expect the parse to
>be '(i ? j : k) = 5' indicates that perhaps the Committee mis-fixed the
>grammar.

The grammar was changed this way to allow throw expressions, which are
currently considered a type of assignment expression with the same precedance,
within conditional statements.  (According to Chapter 19 of ARM '94 reprint).

----------------------------------------------------------------------------
 Richard Deken                   Graduate student in electrical engineering
 PGP public key available      Tennessee Technological University
 Internet: rad6938@gemini.tntech.edu        Cookeville, TN, USA