(j3.2006) Dummy arguments, asynchronous, volatile

[Aleksandar Donev]

On Wednesday 19 March 2008 14:04, Van Snyder wrote:

> Otherwise, we don't really
> believe 5.3.4p4 and 5.3.19p2, so we ought to delete them.
The existing words confuse two different goals/approaches. One is to allow an 
object to have a given property, in this case ASYNCHRONOUS/VOLATILE in 
different parts of the code but not in others. The other goal is to mark a 
given object *permanently* and intrinsically as having the said property, 
which is what some of these argument matching rules seem to imply (for 
example, *never* put an async thing in register, never make a temporary copy 
of it, etc.).

If the goal was the second, then there should be rules that say that either 
both or none of the dummy and actual shall have the ASYNC/VOLATILE attribute. 
Then you make sure there is consistency and an object that is subject 
to "side effects" is marked as such everywhere. But then you loose the 
ability to turn optimization on in other parts of the code involving the same 
object.

If the goal was the first, we should do what Van suggested: Delete a bunch of 
silly constraints.

What is there now achieves neither!

More generally, it is likely that the very use of an attribute to achieve this 
kind of thing is a mistake. Much like TARGET is more-or-less a mistake from 
back in the day...But at least TARGET is consistent. Look at the (pages of) 
rules about TARGET across argument calls and what it implies. You need such 
rules for ASYNC/VOLATILE if you really want to make it do something across 
argument passing.

Best,
Aleks