To: J3                                                     J3/25-164
From: John Reid & Hidetoshi Iwashita
Subject:Auto-generic subprograms: specifications
Date: 2025-August-28

References: 24-139r2, 24-147r1, 25-128, 25-129, 25-163


1. Introduction
===============

Formal requirements for auto-generic subprograms were approved by J3 in
24-147r1 and revisions have been suggested in 25-163. Revised
specifications were approved by J3 in 25-129.

Specification s12 says "Assuming that generic-by-type is feasible and we
do it, ...". We decided to do it in 24-139r2, so this needs to change.

Specification s17, specification s17a, and the note that follows can be
greatly simplified by saying that in each specific procedure the
appearance of a generic dummy argument be treated as if it were declared
with specific type, kind type parameters, and rank. This conforms with
the change to the requirements made in 25-163.

The example uses the syntax Rank(*) to declare a generic dummy argument
of any valid rank, which was superseded in 25-128 by the function
MAX_RANK() in the intrinsic module ISO_FORTRAN_ENV. This needs to change.
Also the example needs to be changed to use this syntax in 24-139r2:
TYPEOF, RANKOF, and SELECT GENERIC RANK.

2. Proposal
===========

We propose that specification s12 be changed to

s12. There shall be a syntax that specifies a set of types for a generic
     dummy argument. This syntax shall be usable for derived types as
     well as for intrinsic types. The dummy argument is still generic
     even if it evaluates to only one type and set of kinds.

We propose that specification s17, specification s17a, and the note that
follows be replaced by

s17. In each specific procedure, each appearance of a generic dummy
     argument shall be interpreted as if its type, kind type parameters,
     and rank had been declared specifically.

We propose that in the example, the line
                Type(Real,Complex), Intent(InOut), Rank(*) :: a, b
be replaced by
                Use ISO_Fortran_env
                Type(Real,Complex), Intent(InOut), &
                                    Rank(0:Max_rank()) :: a, b
the line
                Type(Typeof(b)), Rank(Rank(b)) :: temp
be replaced by
                Typeof(b), Rankof(b) :: temp
and the line
                Select Type (b)
be replaced by
                Select Generic Type (b)


3. Specifications with these changes made
=========================================

Auto-Generic procedure definition and identification:

s01. An "auto-generic procedure" is defined by a "generic subprogram".

s02. A generic subprogram shall be a module subprogram or internal
     subprogram. It shall not have multiple entry points, that is, no
     ENTRY statement is allowed.

NOTE: In principle, this includes the possibility of being a separate
      module subprogram defined in a submodule, in which case there would
      be a generic module procedure interface in the ancestor module.

s03. A generic subprogram that is a module subprogram can have internal
     subprograms; those internal subprograms shall not themselves be
     independently generic.

NOTE: This is to avoid the processor recursively auto-generating procedures
      while it is already in the middle of auto-generating procedures.
      No essential functionality is lost, as the internal procedures can be
      made private module procedures instead.

s04. Every generic subprogram shall have a generic name.

s04a. That generic name may be the same as an existing generic name that is
      accessible in the containing scoping unit.

s05. The name of a generic subprogram shall be able to be added to the
     generic set of a generic identifier that is not a name,
     i.e. operator, assignment, input/output.

s06. There is no specification regarding the ability or inability (as now),
     for adding a generic name that is a traditional generic set to the
     generic set of another generic identifier.
     Consistency may suggest doing this.

Within a generic subprogram:

s07. The subprogram may have zero, one, or more generic dummy arguments.
     Even with no generic dummy argument, it is still a generic subprogram
     providing a generic procedure name and no specific procedure name.

s07a. A generic dummy argument shall be a dummy data object, that is, it
      cannot be a procedure.

s08. There shall be a syntax that specifies all valid kinds of an intrinsic
     type for a generic dummy argument. The dummy argument is a generic
     dummy argument even if a compiler supports only one kind for the type.

s09. There shall be a syntax that specifies all valid ranks for a generic
     dummy argument.

s10. There shall be a syntax that specifies a set of kind type parameter
     values (as constant expressions) for a generic dummy argument. This
     syntax shall be usable for parameterized derived types as well as for
     intrinsic types. The dummy argument is still generic even if it only
     evaluates to one kind (assuming the syntax is different from normal
     non-generic kind specification, which seems likely).

s11. There should be a hopefully-similar syntax for a list of ranks for a
     dummy argument to be generic over. Even if the list of ranks evaluates
     to a single valid rank, the dummy argument is still considered to be
     generic.

s12. There shall be a syntax that specifies a set of types for a generic
     dummy argument. This syntax shall be usable for derived types as
     well as for intrinsic types. The dummy argument is still generic
     even if it evaluates to only one type and set of kinds.

s13. A rank-generic dummy argument shall be a pointer, allocatable, or
     assumed-shape. It may have the CONTIGUOUS attribute, even if rank zero
     is included in the set of ranks.

s14. A generic dummy argument may be polymorphic, if and only if every
     type over which it is generic is an extensible type. None of these
     types may be an extension of another.

s15. The declarations within a generic subprogram shall be consistent with
     every generic combination.

s16. The executable code within a generic subprogram, other than that
     within an ad-hoc specialization construct, shall be consistent with
     every generic combination.

s17. In each specific procedure, each appearance of a generic dummy
     argument shall be interpreted as if its type, kind type parameters,
     and rank had been declared specifically.

s18. The executable code within a block of an ad-hoc specialization need
     only be consistent with the specified generic combination.

NOTE: This is exactly how our existing runtime ad-hoc polymorphism
      constructs work.

s19. Ad-hoc specialization shall be performed at compile time, that is,
     there will be no trace of the non-chosen specializations in the
     generated anonymous specific.

NOTE: This is aspirational, as there is no way at present to express it
      normatively.

s20. A rank, type or kind generic dummy argument may be a coarray.

s21. Coarrays should be better integrated into the generic rules so that it
     becomes possible to have a generic dummy argument that is generic by
     corank.


3. Example
==========

        Module example1
            Interface Operator(.myop.)
                Procedure s ! All of the specific procedures of s.
            End Interface
        Contains
            Generic Subroutine s(a,b)
                Use ISO_Fortran_env
                Type(Real,Complex), Intent(InOut), &
                                    Rank(0:Max_rank()) :: a, b
                Typeof(b), Rankof(b) :: temp
                ...
                Select Generic Type (b)
                Type Is (Real)
                    temp = temp * (1-b)
                Type Is (Complex)
                    ! Just this once, we want the conjugate.
                    temp = temp * (1-Conjg(b))
                End Select
                ...
            End Subroutine
        End Module