To: J3                                                     J3/25-163r1
From: John Reid & Hidetoshi Iwashita & Malcolm Cohen
Subject: Auto-generic subprograms: revised requirements
Date: 2025-October-12

References: 24-147r1, 25-150, 25-156r1, 25-163

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

Formal requirements for auto-generic subprograms were approved by J3 in
24-147r1. When the corresponding edits paper 25-156r1 was being
discussed by J3, a desire was expressed to allow a dummy argument or a
local variable to depend on the type, type parameters, or rank of a generic
dummy argument, without
(a) it being required to have the exact same rank or type parameters,
(b) in the case of another dummy argument, without it needing to be
    independently generic.

Let's call such an entity "generic-dependent" for now.

Here is an example
       generic subroutine sub(a,b)
           real, allocatable, rank(1:2) :: a
           real, allocatable, rank(rank(a)+1) :: b

So, argument A would be generic, and take part in generating the set of
generic combinations.

But argument B would be generic-dependent, and not generate combinations
itself.

There are further examples in 25-150.


2. Discussion
=============

Re (a), requirement f only says that we want to have local variables of
the same type/kind/rank as a generic argument, not arbitrary dependencies,
the obvious being "rank+1". This needs to be updated.

Re (b), the wording of requirement d might lead one to think we did not
intend to have generic-dependent arguments, even though we wrote several
examples of them!

Since we do want them, we should add a new requirement, and tweak "d" to
avoid confusion. We will call the new requirement "d2", so that we don't
need to "re-letter" the requirements at such a late date.

We also noticed that the wording of requirement e could be improved, so
that has been done too. No technical effect.

NB: We've put the old wording of d, e, and f at the bottom of the paper,
    for reference without having to look up old papers.


3. Revised formal requirements
==============================

a. There shall be a mechanism for defining an auto-generic procedure,
   with a single procedure body rather than a set of specific procedures.

b. Such a generic procedure will have a generic name, but no specific
   name.

c. There shall be a mechanism for defining a generic procedure with a
   generic identifier that is an operator name, assignment, or
   input/output.

d. An auto-generic procedure may have zero, one, or more "generic" dummy
   arguments; a generic dummy argument is specified to potentially have
   more than one value for a kind type parameter, more than one rank, or
   more than one type.

d2. An auto-generic procedure may also have a result or dummy arguments
    whose type, kind type parameter value(s), or rank, depends on a
    generic property of a generic dummy argument.
    The dependence need not be identity: e.g. rank(a) + 1.
    Such an argument is not itself a "generic dummy argument", and does
    not increase the number of generic combinations.

NOTE: The proposed template facility has extensive features for handling
      different types; this is not meant to duplicate those. The
      motivating examples for different type are:
        (ex1) algorithms which work the same for real and complex;
        (ex2) algorithms which work the same for an intrinsic type such as
              real, and also for a user-defined type which provides a
              variation on such an intrinsic type.

NOTE: Requiring the type dependency to be more general than "the same type"
      means that we want the following example to be valid:

        Generic Subroutine sub1(a, b)
          Type(t1_list, t2_list) :: b
          Type(Typeof(b%data)), Rank(0:3) :: a

    Outside of sub1 we have declarations of types t1, t2, t1_list, and
    t2_list. Only t1_list and t2_list need any explanation:

        Type t1_list
          Type(t1) :: data
          Type(t1_list),Pointer :: next
        End Type

    t2_list will be similar.

    This might look like we are to some extent duplicating features
    available via the template facility, but this example only works when
    one already has list types defined, so is not doing nearly as much work
    as a template would usually be doing. (Indeed, the list types might
    themselves be defined via a template, but that doesn't mean we should
    need to use a template to generate all our user procedures at once.)

e. As implied by the above, such a generic procedure implicitly defines an
   anonymous set of specific procedures, one for every combination of type,
   kind type parameter value, and rank, of the generic dummy arguments.
   We will call each such combination a "generic combination".

f. A local variable of an auto-generic procedure can have a type, kind type
   parameters, or rank, that depend on a generic dummy argument. Function
   result variables similarly. Such a dependency need not be identity:
   e.g. rank(a) + 1.

g. There shall be a construct for ad-hoc specialization of executable code
   for the type and/or kind type parameter values of a dummy argument that
   is generic in type and/or kind.

NOTE: We already have such a construct for runtime polymorphism, but this
      requirement means compile-time polymorphism.

h. There shall be a construct for ad-hoc specialization of executable code
   for the rank of a dummy argument that is generic in rank.

NOTE: We already have such a construct for runtime rank variability, but
      this requirement is for compile-time rank variability.

i. If possible, this generic procedure facility should be available for
   generic type-bound procedure definition.

j. If possible, this generic procedure facility should be available within
   a template.

k. If possible, this generic procedure facility should be available as a
   separate module subprogram, i.e. using a submodule.


4. Previous wording of d, e, and f requirements
===============================================

d. An auto-generic procedure may have zero, one, or more "generic" dummy
   arguments; a generic dummy argument is one that might have more than
   one value for a kind type parameter, more than one rank, or more than
   one type.

e. As implied by the above, such a generic procedure implicitly defines an
   anonymous set of specific procedures, one for every combination of type,
   kind type parameter value, and rank. We will call each such combination
   a "generic combination".

f. A local variable of an auto-generic procedure can have the same type,
   type parameters, and/or rank, as a generic dummy argument. Function
   result variables similarly.

===END===