(j3.2006) Would there be a technical problem if...

[Bill Long]

> On Jan 17, 2018, at 4:02 PM, Van Snyder <Van.Snyder at jpl.nasa.gov> wrote:
> 
>> 
>> Interestingly in section on procedure reference, the data-ref in the
>> call statement is allowed to be an array.  What that means in the case
>> of the dummy being a scalar and the procedure not elemental is
>> unclear.
> 
> Do we need an interp to resolve the discrepancy between type-bound
> procedure definition and reference?  I'd prefer that the dummy be
> allowed to be an array, and the actual's rank has to match.  I wouldn't
> object to requiring the dummy to be assumed shape, but for now I can't
> think of a reason to require it.

One option would be to add a Note observing that for the data-ref being an array requires that the TBP be elemental.  That would be consistent with the existing standard. However, it provides different semantics than allowing the dummy to be an array.  I don?t think there is an implementation issue with a passed-object  array dummy being explicit shape, assumed size,  assumed shape, or even assumed rank.  The requirement on it being polymorphic already involves a sufficiently complicated calling convention that all those options are basically already covered. 

I looked in the C++ 11 standard and found  "	? In the body of a non-static (9.3) member function, the keyword this is a prvalue expression whose value is the address of the object for which the function is called.?.  Sort of suggests there is only one object, rather than an array of them.   Not that we?re restricted to doing exactly what C++ does. 

Cheers,
Bill


Bill Long                                                                       longb at cray.com
Principal Engineer, Fortran Technical Support &   voice:  651-605-9024
Bioinformatics Software Development                      fax:  651-605-9143
Cray Inc./ 2131 Lindau Lane/  Suite 1000/  Bloomington, MN  55425