To: J3                                                     J3/24-181
From: Malcolm Cohen
Subject: Comment (9) on auto-generic subprogram syntax
Date: 2024-October-27
References: 24-139r2, 24-168


1. Introduction

Paper 24-168 suggests a different syntax for generic rank specification.
Subgroup finds that syntax unacceptable, and suggests a third syntax
(which is mentioned in 24-139r2 itself, actually).


2. Ambiguities and inconsistencies

Comment (9) suggests three changes to the generic rank syntax, but only
provides reasoning for one of those. Perhaps the other changes were
inadvertent.

Change 1: Allow RANK(scalar-int-constant-expr) as a generic rank spec.

This is forbidden by 24-139r2, which has the constraint

     C8nn If a generic-rank-list contains no * or generic-rank-range, it
          shall contain at least two <scalar-int-constant-expr>s.

The reason for this is ambiguity: RANK(3) already has a meaning in Fortran,
so we cannot allow it to specify generic rank.

Thus subgroup rejects this change.

Change 2: Require a scalar-int-constant-expr in a generic rank spec to be
          less than or equal to the maximum supported rank.

The reason this requirement was omitted in 24-139r2 was consideration of
portability; for that reason, such a requirement does not apply to the rank
guards in a SELECT RANK construct.

If there is a MAX_RANK constant or function in ISO_FORTRAN_ENV, as we
expect there will be, this would be a reasonable requirement for the
upper rank-spec.

Thus subgroup approves this change, for the upper rank-spec only, subject
to a satisfactory MAX_RANK being added.

A contrived example of where a lower rank-spec being out of range would be
useful for portability would be where one wishes to be generic over square
ranks, e.g.
    RANK(1,4,9,16:MAX_RANK,25:MAX_RANK,36:MAX_RANK)
That 16, 25, and 36 might be greater than MAX_RANK is harmless, it just
means that those cases might add no ranks to the generic rank list.


3. The main proposed change in 24-168 is to generic-rank-range syntax

The current syntax is:

generic-rank-range is scalar-int-constant-expr : scalar-int-constant-expr

23-168 proposes making both the lower and upper ranks optional, with
default values being zero for the lower rank and MAX_RANK for the upper
rank.

Further, 24-168 proposes dropping the RANK(*) syntax, as RANK(:) would
suffice.

Subgroup is opposed to the first of these changes. There has been expressed
interest in some kind of "deferred rank" feature for some time now, and the
obvious syntax for such a feature would be RANK(:). We should not burn this
syntax for a minor convenience.

Subgroup further considers that explicit values are better than default
values; the lower default being zero is not completely obvious (some might
expect an array to be at least rank one), and the tiny saving by omitting
a single "0" or "1" or "MAX_RANK" is negligible. Requiring the user to type
RANK(1:MAX_RANK) instead of RANK(:) or RANK(*) is not a large burden, and
serves to bring the extent of the rank genericity clearly to the reader's
attention.

Paper 24-139r2 itself had doubts as to whether RANK(*) was good syntax, as
inside SELECT RANK, RANK(*) means assumed-size. (It has no such meaning
outside of SELECT RANK.)

Therefore subgroup is not opposed to the dropping of the RANK(*) syntax, as
long as a suitable MAX_RANK is available.


4. Subgroup recommendations

(a) That in a generic-rank, a scalar-int-constant-expr as the upper rank in
    the specification shall be less than or equal to the maximum rank
    supported by the processor.

(b) That the RANK(*) syntax be omitted, with concomitant changes to the
    constraint following the generic rank syntax rules.

===END===