(j3.2006) (SC22WG5.4341) [ukfortran] 10-208r1
malcolm at nag-j.co.jp
Thu Oct 14 11:12:14 EDT 2010
Reinhold bader wrote:
> I do not understand
Then I'm sorry but we have spelled it out twice now - once in 2008, and now in 2010.
If the dynamic type of object "o_foo" were "badfoo", the call to
the type-bound procedure cannot be resolved without enquiring the
type of o_foo%badcomponent on image 2 (because it needs to know
how much to copy, and how); this type is not necessarily the
same type as that of o_foo%badcomponent on image 1.
The whole point of the changes in 2008 (which I personally was not in favour of, but that is a horse of a different colour) was to remove any possibility of inquiring the type of a polymorphic object on another image.
> (2) copy object from remote image to invoking image
That's the problem. You can't do that. You can't do that because it has a polymorphic allocatable subcomponent. On another image. Copying the object involves copying the allocatable subcomponent. Which requires knowing what *its* type is - not just how big it is itself but also whether *it* has any further allocatable subcomponents. That requires inquiring the type of that subcomponent, and that subcomponent only exists on the remote image, not the local image. The entire point of the changes we made in 2008, in the paper you referenced, was so that we would NOT need to inquire the type of a polymorphic object on another image.
Maybe you think not being able to inquire the type of a remote object is a horrible restriction, and if so I'd agree with that, but that is unfortunately what we agreed to.
Or if you think not being able to inquire the type of a remote object is fine, well then there is no choice but to accept the consequences - which are that the compiler too cannot inquire the type. And in the situation inquired about in 10-208, the compiler would need to do exactly that.
More information about the J3