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".