To: J3                                                     J3/21-187
From: Tom Clune
Subject: Generics subgroup activity report
Date: 2021-October-17

Reference: 21-144r4

1. Introduction

Subgroup along with a few members of the wider Fortran committee
continue to meet regularly to discuss how to provide for generic
programming in Fortran.  Recently we switched from biweekly to
weekly meetings.  The times of these meetings float slightly to
maximize occasional participation by everyone.

At meeting 224, generics subgroup introduced a use cases paper that
was sufficient to drive solutions that would accommodate a broader set
of use cases that were endorsed by subgroup.  However, more recent
discussions have found a variant use case that would not have been
adequately covered by requirements derived from the initial suite.
The short description is a scenario in which a procedure requires
access to private components of two separate instantiations of the
same templated derived type.  An updated use case paper is being
prepared.

Prior to the discovery of the use case mentioned above, analysis
indicated that templating at the level of modules (e..g, Parameterized
Modules) would be sufficient.  This new use case would require either
templated derived types that can be instantiated within their host
module, or some new mechanism for accessing private components of data
types from outside their host module.


3. Formal requirements

Progress on developing a draft requirements paper has been much slower
than was anticipated at the last meeting.  The following is a very
rough list of formal requirements that have general support by
subgroup:

  A. Named templates shall be provided.

  B. Named restrictions shall be provided. (See below)

  C. A templated entity shall be one of the following:
     - module
     - derived type
     - procedure

  D. A template shall have one or more template parameters.

  E. A template parameter shall be one of the following
     - type name
     - constant expression
     - operator
     - procedure

  F. A template shall be instantiated by specifying a value for each
     template parameter.

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

     Note that this is somewhat contrary to the existing situation
     where two otherwise identical derived types define distinct
     types.

  H. Generic programming shall provide means by which a derived type
     can be instantiate within a scope that permits access to its
     private components.

     This allows a class of algorithms involving multiple
     instantiations and that require private access to private
     components.  Use case paper describes a mapping function that
     transforms a container of type T into a container of type U.

     The approach advocated here is to allow derived types to be
     templated.  Other approaches would be to invent new syntax that
     would allow access to private components by other means.  E.g.,
     something vaguely like submodules.

  I. A named restriction shall have a set of one or more parameters.

  J. A named restrictions shall have a set of relations.
     E.g., T + U => V

  K. A restriction parameter shall be one of
     - type name
     - operator

  L. Named restrictions shall be accessible from other modules.

  M. A template shall have a (possibly empty) set of restrictions.

  N. A template instantiation shall satisfy all restrictions specified
     by a template.



4. Partial list of unresolved concerns:

   1. Can a templated module have submodules?

   2. What types of relations can be specified in a restriction.

   3. How to simplify use of TKR in the context of a template parameter?

   4. Should the class of template parameters be expanded to include
      attributes?  In particular ALLOCATABLE?

   5. Should some form of compile-time conditional on template
      parameters be supported?


===END===