Hi Bill,
Having the buffer automatically acquire this new attribute is necessary if we want to avoid requiring changes to existing codes. This is raising red flags for me. Existing codes are *buggy*, and trying to somehow make them conforming and well-behaved seems doomed to me. Even for Fortran ASYNCHRONOUS, the user still has to make sure the attribute appears where it needs to. For one thing, the attribute does not "carry over" between scoping units, so if the dummy has the attribute (magically or explicitly), whether the actual needs it or not is a programming question that the compiler cannot answer. Also, I do not now whether in F2003 the interface of a procedure has to specify ASYNCHRONOUS if the dummy gets it implicitly because it is used in async I/O statements inside the routine??? I think we should stay away from magic, it will turn black easily...
� �2) Most people seem to agree that a data attribute is essential, and a purely procedure-based solution will not work.
Do you agree with this and, if not, why not?
The question hints at a common confusion. Please answer the actual question.
There are TWO basic problems we are trying to address. Except that the two are tied together, just as WAIT and ASYNCHRONOUS go together (read your answer to question 1).
�Various solutions to this problem have been discussed, most centering on an attribute for dummy arguments If so, your answer to question 2 is yes?
or coding versions of the MPI routines that accept pass-by-descriptor rather than pass-by-address for the buffer argument. Answer to question 2 is no---something new is proposed. Are you proposing something new or do you prefer an ASYNCH_EXTERNAL attribute? Or maybe you prefer not to do anything at all (i.e., ignore the issue).
Thanks, Aleks