To: J3                                                     J3/24-184
From: Malcolm Cohen
Subject: Comments (4,5,8) on auto-generic subprogram syntax
Date: 2024-October-29
References: 24-139r2, 24-168


1. Introduction

24-168 says, in comment (4), that there are missing commas in 24-139r2 in
the rules under x04. That is correct: 24-139r2 should have the commas
inserted. Also, the rules have missing optionality brackets: these too
need to be inserted.

24-168 says, of length type parameters for auto-generic dummy arguments,

  In (4), (5) and (8), I don't understand what would be improved by
  disallowing integer constant expressions. I think that, for both users
  and compilers, it would be easier what is allowed in non-generic
  subprograms was also allowed in generic subprograms.

This paper explains the reasons for disallowing them.


2. Discussion

24-139r2 rather glibly says

     Comment
     Length type parameters do not participate in generic resolution, so
     this simplification is mostly about saving the user's toes.

without properly explaining why.

The reason is twofold:

(1) because length type parameters do not participate in generic
    resolution, there is no functionality added by permitting them to be
    anything other than assumed or deferred;

(2) permitting the length type parameter to be non-assumed non-deferred
    creates the possibility of error (i.e. when the actual length differs
    from the dummy length) - such an error could cause error termination
    by a processor that detects such violations, or incorrect results, or
    memory corruption, or a program crash.

Having a feature that creates the possibility for error, with no added
functionality, would go against one of the purposes of the standard,
that is, "to promote ... reliability" (Clause 1, paragraph 1, second
sentence).

In the situation where the actual argument *needs* to have a length type
parameter with a specific length, and error termination is desired if it
is not that length, this case be achieved portably by using assumed length
and an IF statement, for example:
    IF (LEN(x)/=13) ERROR STOP 'x is not of length 13'

Thus, requiring the length to be assumed (or deferred, if it is allocatable
or a pointer) only simplifies the feature to a small extent, but minimising
the opportunities for user error is important.


3. Subgroup recommendation

The missing commas (and missing optionality brackets) in 24-139r2 x04
should be corrected: that makes the syntax rule read

     R8nn gen-char-type-params
        is gen-char-len [ , [ KIND = ] int-constant-expr ]
        or LEN= gen-char-len [ , KIND= int-constant-expr ]
        or KIND= int-constant-expr [ , LEN= gen-char-len ]

The requirement for both CHARACTER type and parameterized derived type,
that they shall have assumed or deferred length type parameters,
should stay as is in 24-139r2.

===END===