[J3] Discussion on F18/031 (CO_BROADCAST)

[Bader, Reinhold]

J3,

21-184r1 says that more discussion is needed on F18/031. I have the following thoughts on this:

Item (1) in 10.2.1.2 of 18-007r1 restricts intrinsic assignment as follows:

"if the variable is polymorphic it shall be allocatable and not a coarray"

Before turning this into an argument in favour of disallowing polymorphism for the argument A in
CO_BROADCAST, I think one should consider what rationales underly the above rule. To my knowledge,
the "bad situations" that can happen in an assignment are:


(A) the RHS may be an extension type of the variable, so you need to reallocate the LHS to guarantee the complete value is copied

  (and with the correct dynamic type)

(B) for coarrays, symmetry would be violated because the RHS has different types on different images



Both of these appear to me to be not relevant to the case of CO_BROADCAST, since there exist additional restrictions on the

argument A that cause problematic situations to be non-conforming anyway:



First,



[355:19]  "A shall have the same shape, dynamic type, and type parameter values, in corresponding references"



This guarantees that (A) cannot happen in a conforming program. It might not be possible to identify a conformity issue

at compile time, but that seems analogous to passing an assumed-shape (non-polymorphic) array (i.e. the extents

are unknown at compile time). Also, the wording indicates that polymorphic objects are intended to work, although
it is true that the exact way the assignment should be performed is insufficiently specified.



Second,



[331:24-25] If the A argument in a reference to a collective subroutine is a coarray, the corresponding ultimate arguments

                      on all active images of the current team shall be corresponding coarrays as described in 5.4.7.



This guarantees that for a conforming program (B) cannot happen, because in the polymorphic case the dynamic type is

guaranteed to be the same on all images.



My conclusion is that forbidding polymorphism altogether is indeed unnecessarily draconian.



>From a practical point of view, it surely also is relevant to identify non-conforming programs. As hinted above, this would

require run-time checks (maybe only available for debug-level compiler switches, to avoid performance issues). For the

polymorphic case, this involves evaluating the type information stored in the object. This seems to indicate that it

is appropriate to exclude the unlimited polymorphic case in CO_BROADCAST, since the dynamic type might be

SEQUENCE or BIND(C) and hence lack that information.



I therefore suggest that the resolution for this interp should be based on the alternative edit in 21-151, with the additional

proviso that an unlimited polymorphic A is not permitted.



Regards

Reinhold















-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20211105/715bf51d/attachment.htm>