[J3] Discussion on F18/031 (CO_BROADCAST)

[John Reid]

Reinhold,


Bader, Reinhold via J3 wrote:
>
> 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)
>

They just have to be type compatible so the LHS could be an extension of 
the RHS. Again reallocation is needed.

> (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.
>

Well, it does say "as if by intrinsic assignment" and this (as you 
pointed out above) requires polymorphic variables to be allocatable. The 
interp. remarks that it is strange to allow nonallocatable polymorphic
broadcast across images while intrinsic assignment within a single image 
is not permitted if the variable is nonallocatable polymorphic.
>
> 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.
>

The big advantage here is that if we require polymorphic A to be 
allocatable, only type compatibility is needed which can be checked at 
compile time. This is the same as for intrinsic assignment.
>
> 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.
>

I see this as too big a change. We should just allow allocatable 
polymorphic A.
>
> Regards
>
> Reinhold
>