To: J3 09-185 From: R. Bader Subject: TR29113 - assumed rank entities Date: 2009 April 10 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 assumed-size 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. Since there appears to be a strong analogy with polymorphism, it is also suggested to change the naming of such an entity from "assumed rank" to "dynamic rank".