To: J3                                                     J3/22-123
From: Van Snyder
Subject: Comments on Generics Formal Specs
Date: 2022-February-21
Reference: 22-120r1

In general, existing mechanisms should be used where possible instead of
inventing new ones that have the same purpose.

B. Named restrictions shall be provided.

A less hand-wavy syntax is interface blocks and bodies for dummy
parameters. If a restriction applies to a dummy parameter type, it can
be expressed as a type-bound procedure.

C2. A template can define any of the following entities:

Enumeration types (and their enumerators) should be on the list.

Named constants should be on the list.

D. A template dummy parameter must be one of the following

Modules should be allowed. If a dummy parameter module is accessed by
use association, the ONLY clause should be required to appear.

Templates should be allowed, along with a prohibition against a template
instantiating itself either directly or indirectly.

Within the type definition in the hand-wavy example, a declaration of a
component and a type-bound procedure part would be illustrative.
Discussion of that should specify that component and type-bound
procedure declarations within dummy paramater type definitions are
minimum requirements, not exclusive requirements, and no order is
implied.

Near the end, SUBROTUINE should be SUBROUTINE

E. A template shall be instantiated ....

It is necessary that an instantiation have a name. Accessing things from
it should be essentially the same as use association, including ONLY and
renaming.

If instantiating a template automatically makes its guts accessible in
the instantiating scope, name clashes could result. So
instantiation and use must be a two-step process:

  INSTANTIATE LOCAL_TMPL => TMPL(INTEGER(KIND=INT32))
  USE LOCAL_TMPL, only: My_Get => Get_Ith

As for use association, the "only" clause applies only to identifiers.
If "Get_Ith" needs other stuff from the instance, that's OK, but the
identifiers of those entities are not available.

Alternatively, ONLY and renaming should be allowed on the INSTANTIATE
statement.

This might clash with item F.

F. Multiple instantiations of a given template with identical
     template actual parameters define the same entities.

Does this apply only within one scoping unit, or every scoping unit in a
program, or one file-system directory, or the entirety of file systems
on one computer, or the entire cloud, or ....?

G-K concerning RESTRICTIONS and REQUIRES

Restrictions and requirements can be specified by interface blocks,
interface bodies, and other dummy parameter declarations.

L. A template may not use any procedures or operators except those
     that have been specified in a REQUIRES statement.

This restriction can be handled by PROCEDURE statements, and
non-overridable (but confirmable) IMPLICIT NONE(TYPE,EXTERNAL).
Presumably, it does not apply to intrinsic procedures, or procedures
accessed from intrinsic modules. Prohibiting use association from
nonintrinsic modules might be a bit too strong. See also item D above
about allowing modules to be template parameters.

UTI-1: Can operator relations in a restriction specify rank?

The "@<int-expr>" syntax for explicit shape declarations should handle
this. But that appears not to have been implemented yet.