To: J3                                                     J3/22-126
From: Van Snyder
Subject: Comments on Generics Specs
Date: 2022-February-24
Reference: 22-120r1, 22-123r1, 22-124

E2. An INSTANTIATE statement must provide the name of an accessible
    TEMPLATE and a list of TEMPLATE actual parameters corresponding to
    the TEMPLATE dummy parameters of the specified TEMPLATE.

E5. The INSTANTIATE feature must allow functionality analogous to the
    ONLY and rename clauses of module USE statements to enable
    disambiguation of provided entities.

An instantiation should be allowed to have a name. Instantiating a
template and getting entities from it could then be a two-step process:

In addition to

       INSTANTIATE :: T(param1, param2), ONLY: S_1 => S

or allow

       INSTANTIATE :: MyT => T(param1, param2)
       USE MyT, only: S_1 => S

and then, in a different scoping unit, perhaps where MyT is accessed by
host or use association

       USE MyT, only: S_2 => S, P

Otherwise, one must re-instantiate the template to get the same thing or
something different from it where needed, perhaps with a different name,
in a different context.

22-120r1 specified that instantiations of the same template with
identical actual parameters produced identical entities. This isn't
mentioned in 22-124. It's not obvious that this would require (or
recommend) a processor to "keep" only one copy of each entity,
especially if such an entity is accessed by more than one identifier.

F. It's not obvious what RESTRICTION is used for. It's not obvious that
it provides anything that is not already provided by interface blocks.
If it's just a way to package parameterized interface blocks, it's not
obvious that it's different from a template.

The meaning of <relation-1> and <relation-2> within the interface block
in F4 is completely opaque. Section I only goes a little way toward
clarifying this.

H. A RESTRICTION can only be referenced by host association or use
   association.

Can a RESTRICTION be declared within a template, and then used therein?

M1. A TEMPLATE may only reference a dummy parameter that is a
    SUBROUTINE, FUNCTION, or OPERATOR if the relevant interface is
    defined in a REQUIRES statement within the TEMPLATE.

The example does nothing to clarify what this means.

M3. A RESTRICTION dummy parameter that is a SUBROUTINE, FUNCTION or
    OPERATOR must be given a single interface.

This is prohibited by existing rules in Clause 19.3.1p3.

Section C of the requirements paper 22-120r1 specified what entities
templates are allowed to define:

      - derived type
      - variable
      - procedure
      - interface

but there is no such specification in 22-124. 22-123r1 recommended
adding

      - enumeration types and their enumerators
      - named constants

Section D of the requirements paper 22-120r1 specified what template
dummy parameters are allowed to be:

     - type name
     - value
     - procedure
     - operator

but there is no such specification in 22-124. 22-123r1 recommended
adding

     - module
     - template

As discussed below concerning template dummy type parameters, it would
be necessary to declare minimum requirements of each to preserve the
possibility of a "strong constraint" model. As with types, the syntax to
declare those requirements would be identical to the syntax to describe
one of the entities that is not a template dummy parameter.

========================================================================

Additional spec:

It is necessary that template dummy parameter type definitions include
component and type-bound procedure declarations, and generic bindings.
Otherwise, procedures within the template cannot access components and
type-bound procedures of objects whose types are dummy type parameters.

Such declarations would require the template actual type parameter to
have components and type-bound procedures with the same characteristics,
but not necessarily in the same order, and would not prohibit additional
components or type-bound procedures.

For example, procedures within a double-linked LIST template would
necessarily need to access PREV and NEXT components, but the application
using an instance would have additional components to represent the
value of the list element.

Because declaration of components in dummy type parameter definitions
would not imply order, and would be minimum, not exclusive requirements,
this would not make it possible to weaken specification M5.