structure assignment, why you would want to do it

[Dave Gillett]

In <1096.26d52ea3 at desire.wright.edu> demon at desire.wright.edu writes:

>In article <3615 at goanna.cs.rmit.oz.au>, ok at goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
[[ whole mess of stuff deleted ]]

>	Thanx!  Everyone wondered why I asked it.  If you are doing
>transformations/similar math stuff or (like I'm doing) vehicle position updates
>for a military simulation, you'd like to be able to say

>pres_location += current_move;

>to update the vehicles location.  I could go through and assign the x,y,z
>locations individually, but it would be nice (and cleaner looking) to do a
>structure assignment.
>        It was intended that the assignement/operator would only be performed
>on like structure elements, and only on elements defined for the operater(s).

Hmmmm....  Richard suggests COBOL semantics, and Brent wants something much
closer to APL semantics (which I'll grant is cheaper to implement, although I
still don't know what the hell either of them expects unions to do...).
Brent's description would *at least* allow us to insist that the structures
be of the same type (APL would allow any conformable type, but that's a bit
much to ask of a compiler) and so corresponding structure elements would
only *happen* to have the same name.

I wonder how often people would try to use this to update some components and
not others.  How often would people forget that arithmetic on chars is legal, 
and turn out to be modifying values they meant to leave unchanged.  How smart
an optimizer would it take to roll up the unrolled loop generated by two
structs that happened to be composed of many ints?

And how often would people discover that "a+a" took an order of magnitude
longer than "b+b" because "a" happened to be a struct?

Brent's intended semantics are almost feasible and almost useful.  Almost...
                                             Dave