To: J3 09-185r1 From: R. Bader Subject: TR29113 - assumed rank entities Date: 2009 April 14 References: N1761, N1766 In N1761, the concept of assumed-rank variable is introduced as a facility to prevent the explosion of number of specifics needed in a generic interface if support is required for all ranks of a particular type. There are two objections to the concept as described in N1761 for which corrections are suggested here by way of informal description. The first issue concerns the lack of a possibility to efficiently reference and define entities inside a Fortran procedure if they are dummy arguments of assumed rank. To enable this, introduction of a new block construct, SELECT RANK, is suggested. SELECT RANK takes a single Fortran entity of assumed rank as its argument. Analogous to SELECT CASE, at most one of the constituent RANK IS blocks, namely that for which the rank selector is equal to the argument entities' actual rank, is executed. Within a RANK IS block, references and definitions of the entity can be performed using a static rank exactly matching that of the rank selector. A RANK OTHER clause, if present, would be executed if no RANK IS block is selected. Within the RANK OTHER block definitions and references of the entity are not permitted; it would however be allowed to provide the entity as an actual argument in a procedure call, where the matching dummy argument is of assumed rank. The second issue relates to the fact that in N1761 the ALLOCATABLE and POINTER attributes are permissible for assumed-rank entities, while they are constrained to be dummy arguments only. This however leads to an inconsistency, since the ultimate actual argument, which might be declared within Fortran, in these cases also needs to be declared to be of assumed rank. To fix this problem, it is either necessary to prohibit the ALLOCATABLE and POINTER attributes for assumed-rank entities, or to relax the dummy argument constraint to also allow declaration of variables with an assumed rank provided they have either the ALLOCATABLE or POINTER attribute. If the latter suggestion is adopted, (1) an ALLOCATABLE entity of assumed rank could be allocated to be of some particular rank ("ranked allocation"), (2) a POINTER entity of assumed rank could be allocated to be of some particular rank, or pointer associated with a type compatible entity of any rank, following the usual rules for pointer association. (3) The actual argument matching a dummy with the ALLOCATABLE or POINTER attribute and assumed rank must have the same attribute and also be of assumed rank. Similar to restrictions already in place for the SIZE and SHAPE intrinsics, the data argument provided to the RANK intrinsic should be prohibited to be an unallocated ALLOCATABLE entity or a disassociated POINTER entity, at least for the case where these entities are of assumed rank. Since there appears to be a strong analogy with polymorphism, it is also suggested to change the naming from "assumed rank" to "dynamic rank".