YAAO (yet another assignment operator)

[Cesar Quiroz]

In a recent article, we are told that 

> Dean Rubine asked for a ->= operator, but this
> is quite impossible (if you try to keep the language
> clean, of course). 

"Impossible" and "Inconvenient" are quite not the same. I 
feel that the proposed YAAO is perfectly possible to implement
(it is even easy to understand), but is not worth the extra 
effort.  More on this below.

>                    -> isn't an operator, it's a syntactical
> construct, like . or [expr].

Ok.  That still makes it clear that the following rule works:

	x ->= y	  means   x = (x->y)  

in the same sense that this rule works:

	x -> y    means   (*x).y

So, the preceding argument doesn't hold.  Moreover, the term 'operator'
need not be restricted to 'arithmetic operator' !  In that light, I
don't get the message of "->" being of a different substance than "+".

> Also, it would be awfull to implement. In a statement
>    p ->= next
> you would have to keep the type of 'p' around, 

Consider this fragment:

/* C code begins */
float x;
...
x += 1;
/* Back to NetLand */

I hope it is generally agreed that you should better remember the
type of x (not to mention its address) until you are done with the
assignment expression.  Otherwise, you may forget to complain/coerce
about the type of the constant 1.  I don't see how the proposal would add
any particularly hairy state keeping requirement.

>                                                and also the
> expression on the righthandside would not be an ordinary
> expression, neither a lvalue nor a rvalue, but something wierd
> (a 'selection expression'?).

Here you are right.  I concur that this is the problem that makes the
addition of the proposed operator inconvenient, it introduces something
not very often seen in C:  implicit/insufficient qualification.
Obviously, the RHS of ->= has to be a structure/union member, but the 
qualification comes from the LHS (one token away can be too far away!).
An additional semantic check would be that the RHS has to be a pointer
and the LHS another pointer to the same type, but that only makes sense
to me.

(Of course, an unrepentant hacker may wish to get the RHS to be any 
expression that the compiler can map as an offset ...)

If this proposal is accepted, a similar argument would call for 
constructs a la Pascal 'with', or some other device to open the
scope of a structure.  Although this may be seen as a conceptually
useful tool, adding it a posteriori will only weaken the language.

> I hope this isn't implemented. It doesn't do a lot of good,
> and it's clearly a very dirty feature.

I myself could find very nice and portable :-) uses for it, but
am not longing for it.

It could be interesting to know what compiler writers/maintainers 
think of the proposals that appear here (or in the mod.* counterpart).
It doesn't help if we can foresee that only a minor number of 
sites will upgrade to a too ambitious standard.

Cesar