(j3.2006) 08-267

[Van Snyder]

On Tue, 2008-09-23 at 14:59 -0700, Aleksandar Donev wrote:
> Hi Van,
> 
> >   select type ( x[1] )
> >   type is ( my_extension )
> >     print *, x%more_stuff
> >   end select
> That is a good point that we missed---we do safe type casts with SELECT TYPE 
> but that acts as an ASSOCIATE construct and you are not allowed to use the 
> coindexed selector here. I am not sure if it is worth trying to fix at this 
> point, unless you have a proposed solution that is simple enough?

I don't have one handy.  Here's a SWAG:  Apply C803 to R803 instead of
R805, and rewrite C616a:

  C616a (R611) Except as the <selector> in a SELECT TYPE statement, if
     <image-selector> appears....

C803 might need some polishing:

  C803 (R803) A <variable> in a <selector> in an ASSOCIATE statement
    shall not be a coindexed object.

> >   call S ( x[1] )
> That was by design---there is no concept of "remote argument association" so 
> in reality this will likely involve a copy of a polymorphic object, which is 
> what Jim objected to (due to implementation complexity and not some 
> fundamental difficulty--we agreed that the implementation cost was not worth 
> the benefit).

I can't find a constraint in 12.5.1 or 08-020 that prohibits a coindexed
actual argument.  Is this a new "design" feature, or is it somewhere
else?  C1230a applies to the <procedure-designator>, and C1237 doesn't
cover it.

Given that one can't reference any component of a polymorphic coindexed
object other than those of its declared type, what's the point of
polymorphic coarrays?

Of course, each image can "pop open" its own coelement without
coindexing it, but why make it part of a coarray if you can't ship it
around?

If we do C616a as in 08-267, we should add a note something to the
effect "There is no point to declaring a polymorphic coarray, except
maybe when modifying a legacy code for parallelism."

Van