To: J3 J3/22-123r1 From: Van Snyder Subject: Comments on Generics Formal Requirements Date: 2022-February-23 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 "@" syntax for explicit shape declarations should handle this. But that appears not to have been implemented yet.