To: J3                                                     J3/24-171
From: Malcolm Cohen
Subject: Formal Requirements DIN-4M: Miscellaneous assumed-rank
Date: 2024-October-21
Reference: 24-136r1, 23-184r1


1. Introduction

This paper proposes formal requirements for DIN-4M, the proposal for
miscellaneous enhancements for assumed-rank arguments.

Some of these come from US-07 "Improve rank-independent functionality".


2. Overview

The following features are being considered:

(1) Allow a simply contiguous assumed-rank argument to be the
    target in a rank-remapping pointer assignment.

(2) Allow an assumed-rank argument to be the selector in a SELECT TYPE
    construct.

(3) Allow a simply contiguous assumed-rank argument to be an actual
    argument for sequence association: that is, when the dummy argument
    is an assumed-size or explicit-shape array.

(4) Allow an assumed-rank argument to be an array constructor value.


3. Potential issues

(a) Scalar (1).
    Rank-remapping pointer assignment currently requires the target to be
    an array, that is, it is not permitted to be scalar.
    If an assumed-rank argument has runtime rank zero, that would violate
    that constraint.

    Possible solutions are:
    (a1) treat this case as if it were an array with a single element;
    (a2) disallow this case at compile time, e.g. by requiring the assumed
         rank argument to be an associate-name of a SELECT RANK construct
         with a RANK(0) clause;
    (a3) disallow this case at execution time, e.g. by specifying error
         termination if it occurs;
    (a4) permit the target of a rank-remapping pointer assignment to be
         scalar, and treat it as if it were a single element array.

    Solution (a1) would appear to be somewhat inconsistent, (a2) works but
    is inconvenient at compile time, (a3) is inconvenient at run time,
    leading us to consider (a4).

    Is (a4) a useful thing to do?

    Does the current requirement for the target to be an array help to
    prevent programming errors?

    Further investigation seems to be needed.

(b) Associate names (2).
    An associate-name can already have assumed rank (in the RANK DEFAULT
    block of a SELECT RANK), so this does not introduce anything new.
    It might, however, raise the question of whether assumed rank should
    be permitted in an ASSOCIATE construct.

    Apart from changing the name, permitting assumed-rank in ASSOCIATE
    appears to have little or no effect, so would add little useful
    functionality; thus it is not recommended.

(c) Sequence association and generic references (3).
    Procedures referenced via generic identifiers may have dummy arguments
    that are assumed-size or explicit-shape, nonetheless the rank of the
    dummy argument is used to match the rank of the actual argument in
    generic resolution.

    This cannot possibly work for assumed rank, as generic resolution is
    only done at compile time.

    Possible solutions are:
    (c1) permit an assumed-rank actual argument only for non-generic
         procedure references;
    (c2) do not add this feature.

    Subgroup considers that solution c1 would be an inconsistency in the
    language, and that this is undesirable.

    Therefore (c2) is recommended, that is, continue to disallow assumed-
    rank arguments as actual arguments when the dummy is not assumed-rank.

(d) Assumed-size arrays in array constructors (4).
    An ac-value that is an array is simply expanded to its elements in
    array element order. So there is no problem with scalar, but there is
    a problem if the assumed-rank argument is associated with an assumed-
    size array.

    Possible solutions are:
    (d1) only allow assumed-rank that is an associate-name of a SELECT RANK
         with a RANK(*) block;
    (d2) specify that this causes error termination;
    (d3) specify that it is treated as zero-sized;
    (d4) specify that it is not allowed so the processor may do anything,
         including error termination or silent wrong answers;
    (d5) omit this sub-feature.

    Solution (d1) certainly solves the issue, but is perhaps inconvenient
    to use and looks a bit kludgey.

    An argument in favour of (d5) is that if the RESHAPE intrinsic is
    permitted on assumed-rank, one can simply do
        RESHAPE(ass_rank, [ size ] )
    instead of
        [ ass_rank ]
    and this is safe (as long as one does not specify too large a size).
    It is slightly more verbose, but easy to understand.


4. Formal requirements

(MR-1) An assumed-rank argument shall be acceptable as the target in a rank
       remapping pointer assignment, as long as it is simply contiguous.

(MR-2) A suitable solution to the scalar inconsistency problem (a) needs to
       be decided. At this point, it looks like relaxing the requirement
       for the target to be an array might be suitable.

(MR-3) A polymorphic assumed-rank argument shall be acceptable as the
       selector in a SELECT TYPE statement. Within the construct, the
       associate names are all assumed-rank.

(MR-4) Assumed-rank arguments remain prohibited for ASSOCIATE.

(MR-5) Assumed-rank arguments remain prohibited for sequence association.

(MR-6) Assumed-rank arguments remain prohibited as ac-values.

===END===