To: J3 10-209 From: R. Bader Subject: SELECT TYPE on a coarray or coindexed object Date: 2010 September 22 Reference: N1814 NUMBER: F08/xxxx TITLE: Resolving the type of a coarray or coindexed object KEYWORDS: coarrays, polymorphism DEFECT TYPE: Request for interpretation STATUS: J3 consideration in progress QUESTIONS: Consider the following code: module m type :: foo integer :: i = 0 end type end module m program p use m class(foo), allocatable :: o_foo[:] integer :: j allocate(foo :: o_foo[*]) if (this_image() == 1) then select type(a => o_foo[2]) type is(foo) j = a%i end select select type(a => o_foo) type is(foo) j = a[2]%i end select select type(o_foo) type is(foo) j = o_foo[2]%i end select end if end program p (1) Is the first SELECT TYPE block standard-conforming? (2) Is the second SELECT TYPE block standard-conforming? (3) Is the third SELECT TYPE block standard-conforming? PROPOSED ANSWERS: (1) No. For the ASSOCIATE construct, C803 disallows a coindexed object to be ASSOCIATEd (to avoid references to coindexed objects without angular brackets). The analogous restriction for SELECT TYPE was overlooked. (2) Yes. This is implied by 8.1.3.3 para 1. (3) Yes. Addition of a NOTE is suggested to emphasize the validity of (2) and (3). PROPOSED EDITS: In 8.1.9.1, para 1, add constraint C837+ (R847) selector shall not be a coindexed object. In 8.1.9.2, after para 8, add NOTE 8.24+ Constraints on the use of coindexed objects ensure that a coindexed object (on the remote image) has the same dynamic type as the corresponding object on the local image. Thus a processor can resolve the type or class of an associating entity on its own image and perform definitions or references on the coindexed associating entity inside the block selected for execution. SUBMITTED BY: R. Bader HISTORY: First draft August 4, 2010 Updated with proposed edits August 5, 2010 Submitted September 22, 2010