To: J3                                                     J3/25-204r2
From: generics
Subject: Consolidated edits for Templates
Date: 2025-November-11
References: 25-135r2, 25-136r2, 25-172r1, 25-173r1, 25-174r2, 25-175r5

Introduction
============

This paper combines 6 previously passed edits papers for templates:

 - 25-135r2 Templates
 - 25-136r2 Deferred arguments
 - 25-172r1 Instantiation
 - 25-173r1 Requirement and Require
 - 25-174r2 Consistency of deferred arguments
 - 25-175r5 miscellaneous edits to other sections

This paper divides the edits into 2 sections.  Section 1 comprises the
first 5 papers above and are meant to be a contiguous new section (or
clause).  Section 2 contains miscellaneous edits to other sections.

Changes from R0:

- Fix wording of Ctt05
- Make constraint forbidding templates from instantiating
  themselves more clear
- Add example in tt.5.3
- Fix example in NOTE 2 of tt.5.4 (missing import statements)
- Add additional explanation to commentary about Ctt61.
- Some other minor grammatical fixes
- Make <prefix> non-optional for templated procedures
- Remove DEFERRED keyword from item that was not intended
  to be deferred in NOTE 2 of tt.4.1.3
- Improve comments in tt.8.2.2 NOTE 2 examples

1. Primary Edits
================

{-------- paper 25-135r2 -----------}


* Insert the following text as a new clause.


tt Type-safe generic programming with templates

tt.1 The TEMPLATE construct

tt.1.1 Syntax for the TEMPLATE construct

A template contains declarations, specifications, and definitions that
are parameterized by deferred arguments.  Instantiation of a template
creates entities based on the definitions in the template, and those
with public identifiers are made accessible to the scoping unit in
which the instantiation appears.

Rtt10 <template> <<is>> <template-stmt>
                        [ <template-specification-part> ]
                        [ <template-subprogram-part> ]
                        <end-template-stmt>

Ctt28 (Rtt10) A <template> shall only appear in the <specification-part>
              of a main program, module, or template.

Rtt11 <template-stmt> <<is>>
          TEMPLATE <template-name> ([<deferred-arg-name-list>])

Rtt12 <end-template-stmt> <<is>>  END TEMPLATE [<template-name>]


Ctt29 (Rtt12) If a <template-name> appears in the <end-template-stmt>,
              it shall be identical to the <template-name>
              specified in the <template-stmt>.

tt.1.2 Template specification part

Rtt13 <template-specification-part> <<is>>
          [ <use-stmt> ] ...
          [ <import-stmt> ] ...
          [ <template-declaration-construct> ] ...

Rtt14 <template-declaration-construct>
          <<is>> <template-specification-construct>
          <<or>> <deferred-arg-decl-stmt>
          <<or>> <requirement>
          <<or>> <template>

Rtt15 <template-specification-construct>
          <<is>> <access-stmt>
          <<or>> <derived-type-def>
          <<or>> <enum-def>
          <<or>> <enumeration-type-def>
          <<or>> <generic-stmt>
          <<or>> <instantiate-stmt>
          <<or>> <interface-block>
          <<or>> <intrinsic-stmt>
          <<or>> <procedure-declaration-stmt>
          <<or>> <type-declaration-stmt>

Ctt30 (Rtt15) If <type-declaration-stmt> is specified, PARAMETER shall
              appear as an <attr-spec>.

Ctt30+ (Rtt15) If <procedure-declaration-stmt> is specified, POINTER
               shall not appear.


{ The implicit mapping within a template scoping unit is the null mapping
  for all the letters - specified in the "misc edits" paper via a change
  to "8.7 Implicit statement". }

NOTE
.............................................................
    A template specification section cannot declare variables or procedure
    pointers.
.............................................................


tt.1.3 Template subprogram part

Rtt16 <template-subprogram-part> <<is>> <contains-stmt>
                                        [ <template-subprogram> ] ...

Rtt17 <template-subprogram>
          <<is>> <function-subprogram>
          <<or>> <subroutine-subprogram>
          <<or>> <templated-function-subprogram>
          <<or>> <templated-subroutine-subprogram>

tt.2 Templated procedures

A templated procedure has the effect of a template that defines a
single procedure.

{ Templated procedures are added to <internal-subprogram> and
  <module-subprogram> by the "misc edits" paper, and so can appear
  anywhere a normal procedure definition can appear. }

Rtt18 <templated-function-subprogram> <<is>>
          <templated-function-stmt>
          <templated-subprogram-specification-part>
          [<execution-part>]
          [<internal-subprogram-part>]
          <end-function-stmt>

Ctt31 (Rtt18) If a <function-name> appears in the <end-function-stmt>,
              it shall be identical to the <template-name>
              specified in the <templated-function-stmt>.

Rtt19 <templated-subroutine-subprogram> <<is>>
          <templated-subroutine-stmt>
          <templated-subprogram-specification-part>
          [<execution-part>]
          [<internal-subprogram-part>]
          <end-subroutine-stmt>

Ctt32 (Rtt19) If a <subroutine-name> appears in the <end-subroutine-stmt>,
              it shall be identical to the <template-name>
              specified in the <templated-subroutine-stmt>.

Ctt33 An internal templated procedure shall not contain an
      <internal-subprogram-part>.

Ctt34 The <internal-subprogram-part> of a templated procedure shall not
      contain a <templated-function-subprogram> or
      <templated-subroutine-subprogram>.


Rtt20 <templated-function-stmt> <<is>>
          <prefix> FUNCTION <template-name>
          ( <deferred-arg-name-list> ) ([<dummy-arg-list>])
          [<suffix>]

Rtt21 <templated-subroutine-stmt> <<is>>
         <prefix> SUBROUTINE <template-name>
         ( <deferred-arg-name-list> ) ([<dummy-arg-list>])
         [<proc-language-binding-spec>]

Rtt22 <templated-subprogram-specification-part> <<is>>
          [ <use-stmt> ] ...
          [ <import-stmt> ] ...
          [ <templated-subprogram-declaration-construct> ] ...

Rtt23 <templated-subprogram-declaration-construct>
          <<is>> <deferred-arg-decl-stmt>
          <<or>> <format-stmt>
          <<or>> <specification-construct>

Ctt35 In either <templated-function-stmt> or
      <templated-subroutine-stmt>, <prefix> shall include TEMPLATE.

tt.3 Restrictions on template definitions

Ctt36 Within a template or templated procedure, or a scoping unit
      nested therein, entities that are not accessed by host or use
      association shall not have the SAVE attribute.

Ctt37 A COMMON or EQUIVALENCE statement shall not appear within a
      template or templated procedure, or a scoping unit nested therein.

Ctt38 A procedure referenced within a template or any nested scope
      therein shall have an explicit interface.

NOTE 1
.............................................................
    Constraint Ctt38 expresses the notion of type-safety.  In particular,
    this allows a template implementation to be verified to be internally
    consistent.
.............................................................

NOTE 2
.............................................................
    Example of a TEMPLATE construct.

    TEMPLATE iterate_tmpl(T, C, S)
       PRIVATE
       PUBLIC :: iterate
       DEFERRED TYPE :: T
       DEFERRED INTEGER, PARAMETER :: C
       DEFERRED INTERFACE
          SUBROUTINE S(x, i)
             TYPE(T), INTENT(INOUT) :: x
             INTEGER, INTENT(IN) :: i
          END SUBROUTINE
       END INTERFACE
    CONTAINS
       SUBROUTINE iterate(x)
          TYPE(T), INTENT(INOUT) :: x
          INTEGER :: i
          DO i = 1, C
             CALL S(x, i)
          END DO
       END SUBROUTINE iterate
    END TEMPLATE iterate_tmpl

    An analogous example to the above using a templated procedure.

    TEMPLATE SUBROUTINE iterate(T, C, S)(x)
       DEFERRED TYPE :: T
       DEFERRED INTEGER, PARAMETER :: C
       DEFERRED INTERFACE
          SUBROUTINE S(x, i)
             TYPE(T), INTENT(INOUT) :: x
             INTEGER, INTENT(IN) :: i
          END SUBROUTINE
       END INTERFACE

       TYPE(T), INTENT(INOUT) :: x
       INTEGER :: i
       DO i = 1, C
          CALL S(x, i)
       END DO

    END SUBROUTINE iterate
.............................................................

{-------- paper 25-136r2 -----------}

tt.4 Deferred arguments

tt.4.1 Declarations of deferred arguments

tt.4.1.1 General

A deferred argument is an entity whose identifier appears in a
<deferred-arg-name-list> in a template, requirement, or templated
procedure.  A deferred argument can be a constant, procedure, or type.
A deferred argument declaration statement is used to declare deferred
arguments.

Rtt02 <deferred-arg-decl-stmt>
          <<is>> <deferred-type-declaration-stmt>
          <<or>> <deferred-const-declaration-stmt>
          <<or>> <deferred-proc-declaration-stmt>
          <<or>> <require-stmt>

tt.4.1.2 Deferred types

A deferred type is a deferred argument that can appear in a type
specifier within a REQUIREMENT construct, TEMPLATE construct, or
templated procedure.

Rtt04 <deferred-type-declaration-stmt> <<is>>
         DEFERRED TYPE[, <deferred-type-attr-list>] ::
         <deferred-type-name-list>

Ctt04 (Rtt04) Each <deferred-type-name> shall be the name of a deferred
              argument of the scoping unit in which the declaration
              appears.

Rtt05 <deferred-type-attr> <<is>> ABSTRACT
                           <<or>> EXTENSIBLE

Ctt05 (Rtt05) ABSTRACT and EXTENSIBLE shall not both appear.

Ctt06 (Rtt05) The same <deferred-type-attr> shall not appear more than
              once in a given <deferred-type-attr-list>.

Ctt07 The name of a deferred type shall not appear as a
      <parent-type-name> in a <type-attr-spec>.

Ctt08 A variable of deferred type shall not be a coarray.

A deferred type with the EXTENSIBLE attribute is an extensible type. A
deferred type with the ABSTRACT attribute is an abstract type. A deferred
type with the ABSTRACT attribute implicitly has the EXTENSIBLE
attribute.

NOTE 1

    A deferred type cannot be extended. The term "extensible"
    implies a restriction on the associated instantiation argument.

NOTE 2

    Even with the EXTENSIBLE attribute, a deferred type cannot be
    constructed because it has unspecified components and type
    parameters within the template.

NOTE 3

    Examples of deferred type declarations are:

        DEFERRED TYPE :: T1
        DEFERRED TYPE, EXTENSIBLE :: T2
        DEFERRED TYPE, ABSTRACT :: T3

NOTE 4

    The distinction between deferred types that are extensible or
    not, and deferred types that are abstract or not, helps to ensure
    a processor can verify a template is internally consistent.  For
    example, a deferred type cannot be used in a CLASS declaration if
    it might be instantiated as INTEGER.  Likewise, a deferred type
    cannot be used in a TYPE declaration if it might be instantiated
    with an abstract type.

    Using the deferred type declarations from NOTE 3, the following
    examples of type declaration statements are valid or invalid as
    marked:

        TYPE(T1)  :: A1   ! Valid
        CLASS(T1) :: A2   ! Invalid

        TYPE(T2)  :: B1   ! Valid
        CLASS(T2) :: B2   ! Valid

        TYPE(T3)  :: C1   ! Invalid
        CLASS(T3) :: C2   ! Valid

NOTE 5

    Variables of deferred type are not permitted to be coarrays because
    it is invalid to coindex a variable that has polymorphic ultimate
    components, and instantiation arguments are permitted to have
    polymorphic ultimate components.  Straightforward workarounds are
    possible using deferred procedures.

{
Future work could relax Ctt08 while introducing a "intrinsic requirement"
that specifies that the type does not have allocatable components. And
this would be checked at instantiate.
}

tt.4.1.3 Deferred constants

A deferred constant is a deferred argument that can appear in constant
expressions.  A deferred constant is a deferred argument that has the
PARAMETER attribute.

Rtt06 <deferred-const-declaration-stmt> <<is>>
           DEFERRED <declaration-type-spec>,
                 <deferred-const-attr-spec-list> ::
                 <deferred-const-entity-decl-list>

Rtt07 <deferred-const-attr-spec> <<is>> DIMENSION(<array-spec>)
                                 <<or>> PARAMETER
                                 <<or>> <rank-clause>

Rtt08 <deferred-const-entity-decl>
          <<is>> <deferred-const-name> [ ( <array-spec> ) ]

Ctt09 (Rtt06) The <deferred-const-attr-spec-list> shall include
              PARAMETER.

Ctt10 (Rtt07) An entity declared in <deferred-const-declaration-stmt>
              shall be INTEGER, LOGICAL, or assumed-length CHARACTER.

Ctt11 (Rtt08) Each <deferred-const-name> shall be the name of a deferred
              argument of the scoping unit in which the declaration
              appears.

Ctt12 (Rtt06) If <array-spec> appears in
              <deferred-const-declaration-stmt>, it shall be
              <implied-shape-spec>, <assumed-or-implied-rank-spec>,
              <explicit-shape-spec-list>, or
              <explicit-shape-bounds-spec>.

Ctt13 (Rtt06) If <implied-shape-spec>, <explicit-shape-spec> or
              <explicit-shape-bounds-spec> appears in
              <deferred-const-declaration-stmt>, then <lower-bound>
              shall not be specified.

Ctt14 (Rtt06) If <explicit-shape-bounds-spec> appears in
              <deferred-const-declaration-stmt>, then
              <lower-explicit-bounds-expr> shall not appear.

NOTE 1
................................................................
    Deferred constant arrays always have default lower bounds.
................................................................
{
 Subgroup prefers to disallow explicit confirmation of default lower
 bounds because we envision that there may be a useful distinction to
 be made in the future between specified lower bounds and default
 lower bounds.
}


NOTE 2
................................................................
    Examples of deferred constant declarations are:

    ! explicit shape
    DEFERRED INTEGER, PARAMETER  :: x1
    DEFERRED INTEGER, PARAMETER :: x2(3)
    INTEGER, PARAMETER :: v1(2) = [5,15] ! not a deferred constant
    DEFERRED INTEGER, PARAMETER  :: x3(v1)

    ! implied shape
    DEFERRED INTEGER, PARAMETER :: x4(*)
    DEFERRED INTEGER, PARAMETER :: x5(*,*)
    DEFERRED INTEGER, PARAMETER, RANK(2) :: x6

    ! assumed-or-implied-rank-spec
    DEFERRED INTEGER, PARAMETER :: x7(..)
................................................................

tt.4.1.4 Deferred procedures

A deferred procedure is a deferred argument that is declared to be a
procedure.  A deferred procedure's interface can be established by a
<deferred-proc-declaration-stmt>, <deferred-interface-body>, or a
<require-stmt>.

Rtt09 <deferred-proc-declaration-stmt> <<is>> DEFERRED PROCEDURE #
                # (<interface>) [ :: ] <deferred-proc-name-list>

Ctt15 (Rtt09) Each <deferred-proc-name> shall be the name of a deferred
              argument of the scoping unit in which the declaration
              appears.

NOTE 1
................................................................
    The interface of a deferred procedure may be defined in terms of
    other deferred arguments.
................................................................

NOTE 2
................................................................
    The following example declares deferred procedures F, S, and G.
    The declaration of G is in terms of an interface F_I.


        DEFERRED TYPE :: T
        DEFERRED INTERFACE
           FUNCTION F(X)
              TYPE(T), INTENT(IN) :: X
              TYPE(T) :: F
           END FUNCTION
           SUBROUTINE S(Y)
              TYPE(T), INTENT(INOUT) :: Y
           END SUBROUTINE
        END INTERFACE
        DEFERRED PROCEDURE(F_I) :: G
................................................................

{-------- paper 25-172r1 -----------}

tt.5 Instantiation

tt.5.1 The INSTANTIATE statement

An INSTANTIATE statement specifies instantiation association.  An
INSTANTIATE statement is a reference to the template or templated
procedure it specifies.

The INSTANTIATE statement provides the means by which a scoping unit
accesses named data objects, nonintrinsic types, procedures, abstract
interfaces, generic identifiers, and namelist groups in a template or
templated procedure. The entities in the instantiation argument list
are instantiation associated with the entities in the template or
templated procedure. The accessed entities have the attributes
specified in the template or templated procedure, except that an
accessed entity may have a different accessibility attribute. The
entities made accessible are identified by the names or generic
identifiers used to identify them in the template or templated
procedure.  By default, the accessed entities are identified by the
same identifiers in the scoping unit containing the INSTANTIATE
statement, but it is possible to specify that different identifiers
are used.


Rtt24 <instantiate-stmt> <<is>> <template-instantiate-stmt>
                         <<or>> <templated-procedure-instantiate-stmt>

Rtt25 <template-instantiate-stmt>
         <<is>> INSTANTIATE [::] <template-name> {
                [ <instantiation-arg-spec-list> ] } [, <rename-list> ]
         <<or>> INSTANTIATE [::] <template-name> {
                [ <instantiation-arg-spec-list> ] }, ONLY : [ <only-list> ]

Ctt40 (Rtt25) The <template-name> shall be the name of a previously
              defined template that is not a templated procedure.

Ctt41 (Rtt25) <template-name> shall not be the name of any construct in
              which the instantiate statement appears.

Rtt26 <templated-procedure-instantiate-stmt> <<is>>
          INSTANTIATE :: <local-name> => <template-name> {
          [ <instantiation-arg-spec-list> ] }

Ctt42 (Rtt26) The <template-name> shall be the name of a previously
              defined templated procedure.

Ctt42+ (Rtt26) <template-name> shall not be the name of any construct
              in which the instantiate statement appears.


A <template-instantiate-stmt> without the ONLY option provides access
to all public entities of the referenced template.  A
<template-instantiate-stmt> with the ONLY option provides access only
to those entities that appear as <generic-spec>s, <use-name>s, or
<use-defined-operator>s in the only list.

An accessible entity of the referenced instantiation is associated
with one or more accessed entities, each with its own identifier.
These identifiers are

   - the identifier of the entity in the referenced template if that
     identifier appears as an <only-use-name> or as the
     <defined-operator> of a <generic-spec> in any <only> for that
     instantiation,
   - each of the <local-name>s or <local-defined-operator>s that the
     entity is given in any <rename> for that instantiation, and
   - the identifier of the entity in that referenced template if
     that identifier does not appear as a <use-name> or
     <use-defined-operator> in any <rename> for that instantiation.


tt.5.2 Inline instantiation of templated procedures

A templated procedure can be instantiated and referenced in
an expression or the <procedure-designator> in a <call-stmt>.

Rtt27 <inline-instantiation> <<is>>
    <template-name> { <instantiation-arg-spec-list> }

Ctt43 (Rtt27) The <template-name> shall be the name of a templated
              procedure.

Ctt43+ (Rtt27) <template-name> shall not be the name of any construct
              in which the instantiation appears.

The procedure designated by <inline-instantiation> is the procedure
produced from instantiating the templated procedure.

NOTE

    Templated procedures cannot reference themselves.

tt.5.3 Template dependence

An entity depends on template T if the entity's declaration or definition
    - instantiates T
    - contains a name that identifies an entity from any instantiation of T
    - contains a name that identifies an entity that depends on T

Ctt43b A template construct shall be ultimately defined
       prior to any entity that depends on it.

Ctt43c A name that appears in a template shall not identify any entity
       that depends on that template.

An entity depends on an instantiation I if the entity's declaration or
definition
    - contains the instantiation I
    - contains a name that identifies an entity from the instantiation I
    - contains a name that identifies an entity that depends on the
      instantiation I

Ctt43d A name that appears as an instantiation argument shall not
       identify an entity that depends on that instantiation.

NOTE 1

     The following is an example that is invalid due to Ctt43b.

     template tmpl()
       type :: U
         type(T) :: x
       end type
     end template

     instantiate tmpl()

     type :: T
       type(U) :: x
     end type

NOTE 2

     A corollary to constraint Ctt43c is that a template cannot
     instantiate itself.


tt.5.4 Interpretation of template instantiation

Multiple instantiations of a given template with the same actual
instantiation arguments identify the same instance of the referenced
template.

NOTE 1

    As a consequence, if a template defines a derived type, two
    identical instantiations of that template define the same type.
    This provides a mechanism for derived types from templates to be
    compatible across scoping units in a convenient manner. For
    example:

        TEMPLATE TMPL{T}
           DEFERRED TYPE :: T
           TYPE :: list_t
              TYPE(T), ALLOCATABLE :: elements(:)
           END TYPE
        END TEMPLATE

        ...

        SUBROUTINE SUB(list)
           INSTANTIATE TMPL{integer}
           TYPE(list_t) :: list
        END SUBROUTINE

        SUBROUTINE DRIVER()
           INSTANTIATE TMPL{integer}
           TYPE(list_t) :: list ! list_t is same type as in SUB
           CALL SUB(list)
        END SUBROUTINE

Two corresponding constant instantiation arguments are the same if and
only if both have the same shape, same type, same type parameters, and
are equal.

Two corresponding type-spec instantiation arguments are the same if
and only if both have the same type and have the same kind and length
type parameters.

Two corresponding procedure instantiation arguments are the same if
and only if both resolve to the same specific procedure.

NOTE 2

    Example showing how procedure instantiation arguments influence
    whether instantiations are the same:

        INTERFACE
           SUBROUTINE F1(x)
              IMPORT MY_T
              TYPE(MY_T) :: x
           END SUBROUTINE
           SUBROUTINE F2(x)
              IMPORT MY_U
              TYPE(MY_U) :: x
           END SUBROUTINE
           SUBROUTINE F3(x)
              IMPORT MY_U
              TYPE(MY_U) :: x
           END SUBROUTINE
        END INTERFACE

        GENERIC :: A => F1, F2
        GENERIC :: B => F1, F3

        TEMPLATE TMPL{T, F}
            DEFERRED TYPE :: T
            DEFERRED INTERFACE
               SUBROUTINE F(x)
                  TYPE(T), INTENT(INOUT) :: x
               END SUBROUTINE F
            END INTERFACE
        END TEMPLATE

        INSTANTIATE TMPL{MY_T, A} ! Resolves to F1
        INSTANTIATE TMPL{MY_T, B} ! Resolves to F1 ==> same

        INSTANTIATE TMPL{MY_U, A} ! Resolves to F2
        INSTANTIATE TMPL{MY_U, B} ! Resolves to F3 ==> different


tt.5.4 Instantiation association

tt.5.4.1 Instantiation arguments

Instantiation arguments are specified by an INSTANTIATE statement, a
REQUIRE statement, or by inline instantiation.

Rtt28 <instantiation-arg-spec> <<is>>
          [ <keyword> = ] <instantiation-arg>

Rtt29 <instantiation-arg> <<is>> <constant-expr>
                          <<or>> <type-spec>
                          <<or>> <generic-spec>
                          <<or>> <procedure-name>

Ctt45 (Rtt28) The <keyword> = shall not be omitted from an
              <instantiation-arg-spec> unless it has been omitted from
              each preceding <instantiation-arg-spec> in the argument
              list.

Ctt46 (Rtt28) Each <keyword> shall be the name of a deferred argument in
              the referenced requirement or template.

The instantiation argument list identifies the correspondence between the
instantiation arguments and the deferred arguments of the referenced
template or requirement. This correspondence can be established either by
keyword or by position. If an argument keyword appears, the instantiation
argument corresponds to the deferred argument whose name is the same as
the argument keyword. In the absence of an argument keyword, an
instantiation argument corresponds to the deferred argument occupying the
corresponding position in the deferred argument list; that is, the first
instantiation argument corresponds to the first deferred argument in the
deferred argument list, the second instantiation instantiation argument
corresponds to the second deferred argument, etc. Each instantiation
argument shall correspond to a deferred argument, and exactly one
instantiation argument shall correspond to each deferred argument.

The entity that is associated with a deferred argument is called its
effective instantiation argument.

tt.5.4.2 Instantiation association of a deferred type

Ctt47 (Rtt29) An <instantiation-arg> that corresponds to a deferred type
              shall be a <type-spec>.

Ctt47+ (Rtt29) A <type-spec> shall specify an intrinsic type, or a
               nonintrinsic type that has been previously defined.

Ctt48 (Rtt29) A <type-spec> shall specify constant type parameters.

Ctt49 (Rtt29) A <type-spec> shall not specify an abstract type if its
              corresponding deferred type does not have the ABSTRACT
              attribute.

{ Judging by C7109 & C7110, just saying "its corresponding deferred type"
  should be sufficient and unambiguous in context. }

Ctt50 (Rtt29) A <type-spec> shall specify an extensible type if
              its corresponding deferred type has the EXTENSIBLE
              attribute.

Ctt51 (Rtt29) A <type-spec> shall not specify EVENT_TYPE, LOCK_TYPE, or
              NOTIFY_TYPE, or specify a type that has a potential subobject
              component of type EVENT_TYPE, LOCK_TYPE, or NOTIFY_TYPE.



NOTE 1
      Constraint Ctt51 ensures that intrinsic assignment is available for
      variables of deferred type.

{A number of places in the standard have a similar exception for these
three types. A separate edit paper could perhaps introduce a name for this
category of types for which intrinsic assignment is not permitted so that
all these constraints can reference a shared term.}

Ctt52 (Rtt29) A <type-spec> shall not specify a type with a coarray
              potential subobject component.

NOTE 2
      Constraint Ctt52 avoids the possibility of assignment
      being invalid where the variable and expr do not agree on
      the allocation status of a coarray component.

A deferred type becomes associated with the type and type parameters
identified by its corresponding instantiation argument.

NOTE 3
      Non-abstract, extensible types can be associated with
      both abstract and non-extensible deferred type arguments.

NOTE 4
      Intrinsic types, SEQUENCE types, and types with the BIND attribute
      cannot be associated with deferred type arguments that have the
      EXTENSIBLE attribute.

      Simple example illustrating the above.

      TYPE :: MY_T1
      END TYPE

      TYPE, ABSTRACT :: MY_T2
      END TYPE

      TEMPLATE TMPL1{T}
         DEFERRED TYPE :: T
      END TEMPLATE TMPL

      TEMPLATE TMPL2{U}
         DEFERRED TYPE, ABSTRACT :: U
      END TEMPLATE TMPL

      INSTANTIATE TMPL1{INTEGER} ! ok
      INSTANTIATE TMPL1{MY_T1}   ! ok
      INSTANTIATE TMPL1{MY_T2}   ! invalid

      INSTANTIATE TMPL2{INTEGER} ! invalid
      INSTANTIATE TMPL2{MY_T1}   ! ok
      INSTANTIATE TMPL2{MY_T2}   ! ok

tt.5.4.3 Instantiation association of a deferred constant

Ctt53 (Rtt29) An <instantiation-arg> that corresponds to a deferred
              constant shall be a <constant-expr>.

Ctt54 (Rtt29) The type and kind type parameters of a <constant-expr> shall
              be the same as the type and kind type parameter of its
              corresponding deferred constant once instantiated.

{
  template tmpl(K, C)
    deferred integer, parameter :: K
    deferred integer(K), parameter :: C
  contains
    subroutine s(...)
      integer :: work_array(C)
      ...
    end subroutine
  end template

  instantiate tmpl(kind(1), 1)
}

Ctt55 (Rtt29) If the shape of the corresponding deferred constant is not
              implied, then the <constant-expr> shall have the same shape.

Ctt56 (Rtt29) If the rank of the corresponding deferred constant is not
              implied, then the <constant-expr> shall have the same rank.

The value of a deferred constant becomes associated with the value of
the constant expression in the corresponding instantiation argument.

tt.5.4.4 Instantiation association of a deferred procedure

Ctt57 (Rtt29) An <instantiation-arg> that corresponds to a deferred
              procedure shall be a <generic-spec> or <procedure-name>.

Ctt58 (Rtt29) A <procedure-name> shall denote a nonpointer,
              nonintrinsic procedure that has an explicit interface.

Ctt59 (Rtt29) The procedure specified by a <procedure-name> shall have the
              same characteristics as its corresponding deferred
              procedure, except that a pure procedure may correspond to a
              deferred procedure that is not pure, a simple procedure may
              correspond to a deferred procedure that is not simple, and
              an elemental procedure may correspond to a deferred
              procedure that is not elemental.

Ctt60 (Rtt29) The generic identifier specified by a <generic-spec> shall
              have exactly one specific procedure that has the same
              characteristics as the corresponding deferred procedure,
              except that a pure specific procedure may correspond to a
              deferred procedure that is not pure, a simple specific
              procedure may correspond to a deferred procedure that is not
              simple, and an elemental specific procedure may correspond
              to a deferred procedure that is not elemental.

Ctt61 (Rtt29) A <procedure-name> shall not be the name of a generic
              identifier.

{Ctt61 is a disambiguating constraint. When the name a <generic-name>
the constraints on <procedure-name> do not apply. Intrinsic procedures
are inherently <generic-name>s.}

If a deferred procedure corresponds to a specific procedure name, it
becomes associated with that named procedure.

If a deferred procedure corresponds to a nonintrinsic generic
identifier, it becomes associated with the specific procedure that is
a member of that generic identifier that has the same characteristics
except whether it is PURE, SIMPLE, or ELEMENTAL.

If a deferred procedure corresponds to an intrinsic generic
identifier, it becomes associated with that intrinsic identifier.

Ctt62 If a deferred procedure corresponds to an instantiation argument
      that is an intrinsic procedure or procedure from an intrinsic
      module, it shall be valid for that procedure to appear where the
      deferred procedure is referenced.


NOTE 1
      If a generic identifier and a specific procedure have the same
      name, the generic identifier takes precedence.

NOTE 2

     Example of instantiation of the template construct from NOTE 2 of
     section tt.4

     INSTANTIATE iterate_tmpl{real, 2, mysub}, mysub_twice => iterate
     CALL mysub_twice(y)

     Example of inline instantiation of the templated subroutine from
     NOTE 2 of section tt.4

     CALL iterate{real, 3, mysub}(y)


{-------- paper 25-173r1 -----------}

tt.6 REQUIREMENT construct

A REQUIREMENT construct specifies characteristics of a set of deferred
arguments, and is intended to facilitate reuse of patterns within
templates and other requirements. A REQUIREMENT construct is a
specification construct and a scoping unit.


Rtt30 <requirement> <<is>>
          <requirement-stmt>
              [ <use-stmt> ] ...
              <requirement-specification-construct> ...
          <end-requirement-stmt>

Rtt30a <requirement-stmt> <<is>>
          REQUIREMENT <requirement-name> { [<deferred-arg-name-list>] }

Rtt30b <end-requirement-stmt> <<is>>
          END [REQUIREMENT [<requirement-name>]]

Ctt63 (Rtt30) A <requirement> shall only appear in the
              <specification-part> of a main program or module.

Ctt65 (Rtt30b) If a <requirement-name> appears in the
               <end-requirement-stmt>, it shall be identical to the
               <requirement-name> specified in the <requirement-stmt>.

Rtt31 <requirement-specification-construct>
          <<is>> <deferred-arg-decl-stmt>
          <<or>> <interface-block>

Ctt66 (Rtt31) The <interface-stmt> within an <interface-block> shall
              include ABSTRACT or DEFERRED.

NOTE

    Each <deferred-arg-name> is local to the REQUIREMENT construct.

tt.7 REQUIRE statement

A REQUIRE statement provides specifications of deferred arguments by
associating them with the deferred arguments of a REQUIREMENT. A
REQUIRE statement is a specification statement.

Rtt32 <require-stmt> <<is>>
          REQUIRE [::] <requirement-name>
          { [<instantiation-arg-spec-list>] }

Ctt67 (Rtt32) A <requirement-name> shall be the name of a REQUIREMENT
              that is ultimately defined prior to the <require-stmt>.

NOTE 1

    Instantiation arguments in a REQUIRE statement are not required
    to be deferred arguments.

NOTE 2

    An instantiation argument that appears in a REQUIRE statement is
    only given an ultimate specification if it is a deferred argument
    of the scoping unit in which the REQUIRE statement appears. See
    tt.2.2.1.

{tt.2.2.1 is "General" in consistency.txt}

NOTE 3

    Examples of REQUIREMENT and REQUIRE:

        REQUIREMENT R1{U, V, G}
           DEFERRED TYPE :: U, V
           DEFERRED INTERFACE
              FUNCTION G(X)
                 TYPE(U), INTENT(IN) :: X
                 TYPE(V) :: G
              END FUNCTION
           END INTERFACE
        END REQUIREMENT

        REQUIREMENT R2{U, G}
           REQUIRE R1{U, U, G}
        END REQUIREMENT

    Example REQUIRE statements for the above requirements are shown below,
    which could appear together in the same template, although they are
    redundant in this case.

        REQUIRE R1{T, T, F}
        REQUIRE R2{T, F}

{-------- paper 25-174r2 -----------}

tt.8.2 Consistency of deferred argument specifications

tt.8.2.1 General

Within a construct with deferred arguments, a direct specification of
a deferred argument is provided by
    - a <deferred-type-declaration-stmt>,
    - a <deferred-const-declaration-stmt>,
    - a <deferred-proc-declaration-stmt>, or
    - an <interface-body> in a deferred interface block
in the scoping unit where the deferred argument appeared in a
<deferred-arg-name-list>.

{The final portion of the above paragraph might be redundant with Ctt04,
Ctt11, and Ctt15.}

A deferred argument shall have one or more ultimate specifications.  The
ultimate specifications of a deferred argument are:
    - a direct specification, if present, and
    - its ultimate specifications as instantiation arguments in
      REQUIRE statements in the scoping unit where the deferred
      argument appeared in a <deferred-arg-name-list>, if any.
The ultimate specifications of an instantiation argument in a REQUIRE
statement are the ultimate specifications of the corresponding
deferred argument in the referenced requirement construct.

Ctt02 A deferred argument shall have at most one direct specification in
      a given scoping unit.

NOTE 1

    A deferred argument is always explicitly declared within the
    template itself or via a referenced requirement.  A deferred
    argument has at least one ultimate specification.

tt.8.2.2 Specification of deferred types

Ctt17 If any ultimate specification of a deferred argument is a
      deferred type, then all ultimate specifications of that
      deferred argument shall be deferred type.

If any ultimate specification of a deferred type has the EXTENSIBLE
attribute, then the deferred type has the EXTENSIBLE attribute.

If all ultimate specifications of a deferred type have the ABSTRACT
attribute, or if the deferred type has a direct specification
with the ABSTRACT attribute, then the deferred type has the ABSTRACT
attribute. Otherwise the deferred type does not have the ABSTRACT
attribute.

NOTE 1

    A deferred type with the ABSTRACT attribute can only be an
    instantiation argument when the corresponding deferred argument
    has the ABSTRACT attribute. Therefore, if a deferred type has a
    direct specification with the ABSTRACT attribute, all of its
    ultimate specifications need the ABSTRACT attribute too.

NOTE 2

    Examples that illustrate valid and invalid uses of ABSTRACT and
    EXTENSIBLE attributes on deferred types are:

        REQUIREMENT R_REGULAR{U}
	   ! Instantiation arg associated with U can be any non-abstract type.
           DEFERRED TYPE :: U
        END REQUIREMENT

        REQUIREMENT R_EXTENSIBLE{U}
	   ! Instantiation arg associated with U has to be extensible
	   ! (e.g., cannot be intrinsic), and cannot be abstract.
           DEFERRED TYPE, EXTENSIBLE :: U
        END REQUIREMENT

        REQUIREMENT R_ABSTRACT{U}
	   ! Instantiation arg associated with U has to be extensible,
     ! and can be abstract.
           DEFERRED TYPE, ABSTRACT :: U
        END REQUIREMENT

    Given the requirements above and deferred arguments T1, T2, ...,
    T15, the following lines are valid or invalid as marked.

  ! Valid, declares T1 non-extensible
        REQUIRE R_REGULAR{T1}

  ! Valid, declares T2, extensible, non-abstract
        REQUIRE R_EXTENSIBLE{T2}

  ! Valid, declares T3 abstract
        REQUIRE R_ABSTRACT{T3}

	! Valid: T4 is specified to be non-extensible.
        DEFERRED TYPE :: T4   ! Declares T4 to be non-extensible
        REQUIRE R_REGULAR{T4} ! Req. T4 to be non-abstract

	! Invalid
        DEFERRED TYPE :: T5      ! Declares T5 to be non-extensible
        REQUIRE R_EXTENSIBLE{T5} ! Req. T5 to be extensible, non-abstract

	! Invalid
        DEFERRED TYPE :: T6    ! Declares T6 to be non-extensible
        REQUIRE R_ABSTRACT{T6} ! Req. T6 to be extensible

  ! Valid: T7 is specified to be extensible, non-abstract
        DEFERRED TYPE, EXTENSIBLE :: T7 ! Declares T7 to be extensible
        REQUIRE R_REGULAR{T7}           ! Req. T7 to be non-abstract

	! Valid: T8 is specified to be extensible, non-abstract
        DEFERRED TYPE, EXTENSIBLE :: T8 ! Declares T8 to be extensible
        REQUIRE R_EXTENSIBLE{T8} ! Req. T8 to be extensible, non-abstract

  ! Valid: T9 is specified to be extensible, non-abstract
        DEFERRED TYPE, EXTENSIBLE :: T9 ! Declares T9 to be extensible
        REQUIRE R_ABSTRACT{T9}          ! Req. T9 to be extensible

	! Invalid
        DEFERRED TYPE, ABSTRACT :: T10 ! Declares T10 to be abstract
        REQUIRE R_REGULAR{T10}         ! Req. T10 to be non-abstract

	! Invalid
        DEFERRED TYPE, ABSTRACT :: T11 ! Declares T11 to be abstract
        REQUIRE R_EXTENSIBLE{T11}      ! Req. T11 to non-abstract

  ! Valid: specification of T12 to be abstract
        DEFERRED TYPE, ABSTRACT :: T12 ! Declares T12 to be abstract
        REQUIRE R_ABSTRACT{T12}        ! Req. T12 to be extensible

  ! Valid: specification of T13 to be extensible, non-abstract
        REQUIRE R_REGULAR{T13}    ! Req. T13 to be non-abstract
        REQUIRE R_EXTENSIBLE{T13} ! Req. T13 to be extensible, non-abstract

  ! Valid: specification of T14 to be extensible, non-abstract
        REQUIRE R_REGULAR{T14}  ! Req. T14 to be non-abstract
        REQUIRE R_ABSTRACT{T14} ! Req. T14 to be extensible

	! Valid: specification of T15 is extensible, non-abstract
        REQUIRE R_EXTENSIBLE{T15} ! Req. T15 to be extensible, non-abstract
        REQUIRE R_ABSTRACT{T15}   ! Req. T15 to be extensible

tt.8.2.3 Specification of deferred constants

Ctt18 If any ultimate specification of a deferred argument is a
      deferred constant, then all ultimate specifications of
      that deferred argument shall be deferred constant.

Ctt19 All ultimate specifications of a deferred constant shall
      specify the same type and kind type parameters.

Ctt20 If any ultimate specification of a deferred constant is of
      a non-implied rank R, then a direct specification of
      that deferred constant shall have rank R, and all other
      ultimate specifications of that deferred constant shall
      either have implied rank or have rank R.

Ctt21 If any ultimate specification of a deferred constant has
      explicit shape S, then a direct specification of that
      deferred constant shall have shape S, and all other
      ultimate specifications of that deferred constant shall
      have implied rank, implied shape, or shape S.

If any ultimate specification of a deferred constant has an explicit
shape S, then that deferred constant has shape S.  Otherwise, if any
ultimate specification of that deferred constant has implied shape,
then it has implied shape with the same rank.  Otherwise it has
implied rank.

tt.8.2.4 Specification of deferred procedures

Ctt22 If any ultimate specification of a deferred argument is a
      deferred procedure, then all ultimate specifications of
      that deferred argument shall be deferred procedure.

Ctt23 Except for the PURE, SIMPLE, and ELEMENTAL attributes, the
      characteristics of all ultimate specifications of a
      deferred procedure shall be consistent.

NOTE

    The characteristics of a procedure do not include the names
    of the dummy arguments, so they need not be the same.

Ctt24 If any ultimate specification of a deferred procedure is
      SIMPLE, then a direct specification of that deferred
      procedure shall be SIMPLE.

Ctt25 If any ultimate specification of a deferred procedure is
      PURE, then a direct specification of that deferred
      procedure shall be PURE or SIMPLE.

Ctt26 If any ultimate specification of a deferred procedure is
      ELEMENTAL, then a direct specification of that deferred
      procedure shall be ELEMENTAL.

If any ultimate specification of a deferred procedure is SIMPLE then
that deferred procedure is SIMPLE. Otherwise, if any ultimate
specification of that deferred procedure is PURE, then it is PURE.

If any ultimate specification of a deferred procedure is ELEMENTAL then
that deferred procedure is ELEMENTAL.

If the names of the dummy arguments of a deferred procedure are the
same in all of its ultimate specifications, then those are the names
of its dummy arguments; otherwise, if the deferred procedure has a
direct specification, the direct specification defines the
names of its dummy arguments; otherwise, the names of its dummy
arguments are processor dependent.

Ctt27 A deferred procedure shall not be referenced with a keyword
      argument if it has any dummy argument whose name is processor
      dependent.


  The following examples demonstrate when it is valid to reference a
  deferred procedure with keyword arguments:

  REQUIREMENT R1(T, S, ...)
    (\textit{Declares subroutine S dummy argument names to be X and Y})
    ...

  REQUIREMENT R2(T, S, ...)
    (\textit{Declares subroutine S dummy argument names to be X and Y})
    ...

  REQUIREMENT R3(T, S, ...)
    (\textit{Declares subroutine S dummy argument names to be A and B})
    ...

  TEMPLATE T1(T, S, ...)
    REQUIRE R1(T, S, ...)
  CONTAINS
    SUBROUTINE EXAMPLE(c, d)
      TYPE(T), INTENT(INOUT) :: c, d
      CALL S(x = c, y = d) ! valid
    END SUBROUTINE
  END TEMPLATE

  TEMPLATE T2(T, S, ...)
    REQUIRE R1(T, S, ...)
    REQUIRE R2(T, S, ...)
  CONTAINS
    SUBROUTINE EXAMPLE(c, d)
      TYPE(T), INTENT(INOUT) :: c, d
      CALL S(x = c, y = d) ! valid
    END SUBROUTINE
  END TEMPLATE

  TEMPLATE T3(T, S, ...)
    REQUIRE R1(T, S, ...)
    REQUIRE R3(T, S, ...)
  CONTAINS
    SUBROUTINE EXAMPLE(c, d)
      TYPE(T), INTENT(INOUT) :: c, d
      CALL S(x = c, y = d) ! invalid
    END SUBROUTINE
  END TEMPLATE

  TEMPLATE T4(T, S, ...)
    REQUIRE R1(T, S, ...)
    REQUIRE R3(T, S, ...)

    DEFERRED INTERFACE
      SUBROUTINE S(w, z)
        TYPE(T), INTENT(INOUT) :: w, z
      END SUBROUTINE
    END INTERFACE
  CONTAINS
    SUBROUTINE EXAMPLE(c, d)
      TYPE(T), INTENT(INOUT) :: c, d
      CALL S(w = c, z = d) ! valid
    END SUBROUTINE
  END TEMPLATE


2. Miscellaneous edits
======================

{-------- paper 25-175r5 -----------}

Clause 3:  Terms and definitions
--------------------------------

[5:5+] Insert new glossary term:

  "3.7.2b
   [deferred argument association]
   association between an instantiation argument and a deferred
   argument

   NOTE 1 to entry: Deferred argument association is described in
   \ref{The INSTANTIATE statement}.

[10:9+] Insert new glossary term

  "3.34.1
  [deferred constant]
  a deferred argument with the PARAMETER attribute"


[11:32+] Insert new glossary terms

  "3.46b
   [deferred argument]
   named entity that appears in a <deferred-arg-list>

   NOTE 1 to entry: Deferred arguments are described in
   \ref{Syntax for the TEMPLATE construct}

[17:18+] Insert new glossary term

  "3.85b
  [instantiation argument]
  entity that determines deferred argument association"

[23:29+] Insert new glossary term

  "3.117b [same instance]
  instantiation of the same template with the same instantiation arguments"

[23:29+] Insert new glossary term

  "3.117c [same statement]
  the statement that is the one in which the subject appears, and if the
  statement is within a template, is from the same instance of the
  template."

{UTI: The above definition could probably be improved}

[24:3] 3.120 scoping unit: Change "or subprogram" to "subprogram,
       template construct, or requirement construct", such that the
       entire definition reads

   "BLOCK construct, derived-type definition, interface body, program
   unit (3.113), subprogram, template construct, or requirement
   construct, excluding all nested scoping units in it"

{Note to editor (3.113 is \ref{program unit} and was already present
in 25-007r1.)}

[27:12] 3.139 subprogram: Change "or subroutine-subprogram (R1537)" to
        ", subroutine-subprogram (R1537), templated-function-subprogram, or
        templated-subroutine-subprogram", such that the entire
        definition now reads:

        "<function-subprogram> (R1532), <subroutine-subprogram> (R1537),
        <templated-function-subprogram> (R???), or
        <templated-subroutine-subprogram> (R???)"


[32:16+] Insert new glossary term

  "3.151b
  [ultimately defined prior]

  accessed by host association with a definition that appears before
  the scoping unit in which it is referenced, or ultimately defined
  prior in the host scoping unit

Clause 5: Fortran concepts
--------------------------


[44:20-28] In 5.1 High level syntax, extend R508
           specification-construct to include new syntax terms:
           <template>, <require-stmt>, <requirement> and
           <instantiate-stmt>, such that it now reads:

   "R508 <specification-construct> <<is>> <derived-type-def>
                                   <<or>> <enum-def>
                                   <<or>> <enumeration-type-def>
                                   <<or>> <generic-stmt>
                                   <<or>> <interface-block>
                                   <<or>> <parameter-stmt>
                                   <<or>> <procedure-declaration-stmt>
                                   <<or>> <other-specification-stmt>
                                   <<or>> <type-declaration-stmt>
                                   <<or>> <template>
                                   <<or>> <require-stmt>
                                   <<or>> <requirement>
                                   <<or>> <instantiate-stmt>
   "

{ Allowing REQUIRE outside of templates is not something that has been
  discussed in plenary, but seems to be a natural thing to allow to
  generics subgroup.  It would provide a means for library developer
  to ensure that their product meets certain requirements without
  regard to any specific (external) template.}

[44:37-38] Extend R512 to include templated procedures such that it
           now reads:


   "R512 <internal-subprogram>
         <<is>> <function-subprogram>
         <<or>> <subroutine-subprogram>
         <<or>> <templated-subroutine-subprogram>
         <<or>> <templated-function-subprogram>"


* 5.3.2 Statement order

[48:1+] Update first line in table 5.1, to include TEMPLATE such that
        it now reads:

   "PROGRAM, FUNCTION, SUBROUTINE, MODULE, SUBMODULE, TEMPLATE, or
    BLOCK DATA statement."

[48:9+] In Table 5.2, delete the row for "statement function".

[48:9+] In Table 5.2, delete the column for "Block data", along with
        it's footnote 2.

{These are to make room for a new entry.}

[48:9+] Add a new column to Table 5.2 Statements allowed in scoping units,
with heading "Template".  The row entries are:

   "
     - USE                   Yes
     - IMPORT                Yes
     - ENTRY                 No
     - FORMAT                No
     - Misc. decl.s(1)       Yes
     - DATA                  No
     - Derived-type          Yes
     - Interface             Yes
     - Executable            No
     - CONTAINS              Yes
    "

[49:2] 5.3.3 The END statement: After "module subprogram", insert ",
       templated subprogram" such that the entire sentence reads:

       "Each program unit, module subprogram, templated subprogram,
       and internal subprogram shall have exactly one END statement."

[49:7] After "end-module-statement", insert ", end-template-statement,
       end-requirement-stmt" such that the sentence now reads:

        "The end-module-stmt, end-template-statement,
        end-requirement-stmt, end-submodule-stmt, and
        end-block-data-stmt statements are nonexecutable."

* 5.4.1.1 General

[51:27+]  After 5.4.1.3 Derived type, add a new subclause:

  "5.4.1.3+ Deferred type

  Deferred types are deferred arguments that are types in templates,
  templated procedures, or requirements.  Deferred types are described
  further in tt.xx."


Clause 6: Lexical tokens and source form
----------------------------------------

[62:4] 6.2.6 Delimiters
   Change  "or /)"  to  "/), {, or }." such that the entire sentence reads:

  "A lexical token that is a delimiter is
   a (, ), /, [, ], {, }, (/, or /)."


Clause 7: Types
---------------

[68:16-19] In section 7.3.2.1 Type specifier syntax, insert
           <deferred-type> in R702 <type-spec> such that it reads:

   " R702 <type-spec> <<is>> <intrinsic-type-spec>
       <<or>> <derived-type-spec>
       <<or>> <deferred-type>
       <<or>> <enum-type-spec>
       <<or>> <enumeration-type-spec> "

[68:20] In C703, after derived-type-spec, insert 'or deferred-type'
        such that it reads:

  "(R702) The <derived-type-spec> or <deferred-type> shall not specify
   an abstract type (\ref{Type extension}) except when it appears as an
   <instantiation-arg>."

[68:21-30] In R703 <declaration-type-spec> insert '<<or>> TYPE (
           <deferred-type> )' after 'derived-type-spec' such that R703
           now reads:

    "R703 <declaration-type-spec> <<is>> <intrinsic-type-spec>
       <<or>> TYPE ( <intrinsic-type-spec> )
       <<or>> TYPE ( <derived-type-spec> )
       <<or>> TYPE ( <deferred-type> )
       <<or>> TYPE ( <enum-type-spec> )
       <<or>> TYPE ( <enumeration-type-spec> )
       <<or>> CLASS ( <derived-type-spec> )
       <<or>> CLASS ( <deferred-type> )
       <<or>> CLASS ( * )
       <<or>> TYPE ( * )
       <<or>> TYPEOF ( <data-ref> )
       <<or>> CLASSOF ( <data-ref> )"

[68:31] Change C705 wording to be consistent with constraints just
        after it:

  "C705 (R703) CLASS(<derived-type-spec>) shall specify an extensible
  type (\ref{Type extension})."

{This is just a wording change, but the original is so glaringly
different than the nigh identical constraint that follows, that
generics subgroup thought it should be updated.}

[68:34+] After C705, insert a new constraint:

   "C705+ (R703) CLASS(<deferred-type>) shall specify an extensible
    type (\ref{Type extension})."

[69:1+] After C706 introduce a new constraint

   "C706+ (R703) TYPE(<deferred-type>) shall not specify an abstract type
   (\ref{Type extension})."

[80:27+] In 7.5.2.1 Syntax of a derived-type definition, insert a new
         constraint on R728 after C737:

   "C737b (R728) <parent-type-name> shall not be a <deferred-type>."


Clause 8: Attribute declarations and specifications
---------------------------------------------------

[113:15] In 8.5.2 Accessibility attribute, in C817, insert "or
         template" after "module", so that it now reads:

  "C817 An access-spec shall appear only in the specification-part of a
       module or template construct."


[118:14] In 8.5.8.1 General, change the last entry for <array-spec>
     from:

            "<<or>> <assumed-rank-spec>"
     to
            "<<or>>   <assumed-or-implied-rank-spec>".

[118:19] Modify R818 to disambiguate lower and upper explicit bounds
         such that it reads:

 "R818 <explicit-shape-bounds-spec>
       <<is>> [ <lower-explicit-bounds-expr> : ]
                    <upper-explicit-bounds-expr>
       <<or>> <lower-bound> : <explicit-bounds-expr>
       <<or>> <explicit-bounds-expr> : <upper-bound>

[118:21+] After R818, insert new rules:

    "R818b <lower-explicit-bounds-expr> <<is>> <explicit-bounds-expr>
     R818c <upper-explicit-bounds-expr> <<is>> <explicit-bounds-expr>"

{If we omit <explicit-bounds-expr>, it means the upper bounds.  But
this complicates wording for a constraint that needs to distinguish
this case.}

[121:21] In 8.5.8.6 Implied-shape array, change "the constant-expr in
         its declaration" to "a constant expression".  Such that it
         now reads:

    "An implied-shape array is a named constant that takes its shape
    from a constant expression."

[121:21] After first sentence, insert new sentence:

     "If it is a deferred constant, it takes its shape from the
      associated instantiation argument, otherwise it takes its shape
      from the constant expression in its declaration."

{Note that this change is a bit larger than strictly necessary.  It is
needed for deferred constants, but it seems natural to include
ordinary constant here.}

[121:27-29] Delete the first sentence of p3 starting with "The extent
            of ...".

[121:30] Change name of section 8.5.8.7 from "Assumed-rank entity" to
         "Assumed-rank or implied-rank entities".

[121:30+] Insert new section heading: 8.5.8.7.1 "Assumed-rank entity"

[121:34] Modify text of the last sentence of p1 change
       "assumed-rank-spec" to "assumed-or-implied-rank-spec", such
       that it now reads:

   "An assumed-rank entity is declared with an <array-spec>
    that is an <assumed-or-implied-rank-spec>.


    R827 assumed-or-implied-rank-spec is ..

    C839 An assumed-rank entity shall be an associate name or a dummy
         data object that does not have the CODIMENSION or VALUE
         attribute.

    C840 An assumed-rank variable name shall not appear in a
         designator or expression except as an actual argument that
         corresponds to a dummy argument that is assumed-rank, the
         argument of the function C_LOC or C_SIZEOF from the intrinsic
         module ISO_C_BINDING (\ref{The ISO_C_BINDING intrinsic module}),
         the first dummy argument of an intrinsic inquiry function, or
         the selector of a SELECT RANK statement.

    C841 If an assumed-size or nonallocatable nonpointer assumed-rank
         array is an actual argument that corresponds to a dummy
         argument that is an INTENT (OUT) assumed-rank array, it shall
         not be polymorphic, finalizable, of a type with an
         allocatable ultimate component, or of a type for which
         default initialization is specified.

[122:8+] Insert new section

    "8.5.8.7.2 Implied-rank entity

     An implied-rank entity is an entity whose rank becomes defined
     only within the instantiation of a template.  The following are
     implied-rank entities:

       - deferred constant declared with <assumed-or-implied-rank-spec>

       - variable, dummy argument, or deferred constant whose rank is
         declared to be a deferred integer, scalar constant expression

       - variable, dummy argument, or deferred constant whose shape is
         declared to be a deferred integer, rank-1 array expression.

{When SELECT GENERIC RANK appears for generic procedures, we will need
to integrate with templates so that it also works with implied-rank
entities.}

    NOTE

        The following are examples of implied-rank entities

        TEMPLATE EXAMPLE(C, S, N)
           DEFERRED INTEGER, PARAMETER :: S(*)
           DEFERRED INTEGER, PARAMETER :: C(..) ! implied-rank
           INTEGER, PARAMETER :: B(S) = 1       ! implied-rank
           REAL, PARAMETER, RANK(RANK(C)) :: D  ! implied rank
        END TEMPLATE

[127:3] In 8.5.17 RANK clause, in C864, replace "a dummy data object
        or" with "a named constant, a dummy data object, or" such that
        it now reads:

    "C864  An entity declared with a rank-clause shall be a named constant,
           dummy data object or have the ALLOCATABLE or POINTER attribute."

{This change is a bit larger than strictly necessary for generic
programming.  We only need to allow it for deferred constants, but it
seems natural to allow for ordinary named constants as well.}

[127:6] In p2, after "it is a deferred-shape array;" insert "
        otherwise, if it is a named constant, it specifies that it is
        an implied-shape array with all lower bounds equal to one;"
        such that the entire sentence reads:

    "If the rank is zero the entity is scalar; otherwise, if it has
    the ALLOCATABLE or POINTER attribute, it specifies that it is a
    deferred-shape array; otherwise, if it is a named constant, it
    specifies that it is an implied-shape array with all lower
    bounds equal to one; otherwise, it specifies that it is an
    assumed-shape array with all the lower bounds equal to one".

[128:36-37] In 8.6.1 Accessibility Statement, in constraint C873, after
            "a module", insert " or template" twice, such that the
            constraint reads:

  "C873 (R831) An <access-stmt> shall appear only in the
        <specification-part> of a module or template. Only one
        accessibility statement with an omitted <access-id-list> is
        permitted in the <specification-part> of a module or
        template."

[129:1-2] In constraint, C874, replace "or namelist group" with
          "namelist-group, requirement, or template" such that the
          entire constraint now reads:

   "C874 (R831) Each <access-name> shall be the name of a module,
         variable, procedure, nonintrinsic type, named constant,
         namelist group, requirement, or template."

[129:2+] Introduce new constraint:

   "C874+ (R831) <access-name> shall neither be a deferred argument
                 nor a host associated entity."


[129:7] In second sentence of p1, insert "or template" after "in the
         module" in both locations such that the sentence now reads:

    "An access-stmt without an access-id list specifies the default
    accessibility of the identifiers of entities declared in the
    module or template, and of entities accessed from a module whose
    name does not appear in any access-stmt in the module or
    template."

[129:9] In last sentence of paragraph 1, insert "or template" after
         "in a module" such that the sentence now reads:

    "If no such statement appears in a module or template, the default
    is public accessibility."

[129:16] In first sentence of paragraph 2, insert "or template" after "in
       the module" such that the sentence now reads:

    "If an identifier is accessed by use association and not declared
    in the module or template, and the name of every module from which
    it is accessed appears in an access-stmt in the scoping unit, its
    default accessibility is PRIVATE if the access-spec in every such
    access-stmt is PRIVATE, or PUBLIC if the access-spec in any such
    access-stmt is PUBLIC.

[129:19+] Introduce a new paragraph after paragraph 2.

    "In a template, deferred arguments and entities accessed by host
     association do not have an accessibility attribute."


[136:30-32] In 8.7 IMPLICIT Statement, replace the last sentence of
            paragraph 3 with

   "If a mapping is not specified for a letter, the default mapping of
     - a program unit, or
     - an interface body outside a template scoping unit or templated
       subprogram
    is default integer if the letter is I, J, ..., or N and default real
    otherwise.

    If a mapping is not specified for a letter, the default mapping for
    a BLOCK construct, internal subprogram, or module subprogram is the
    mapping in the host scoping unit.

    The mapping for a template construct, a templated subprogram, or
    an interface body that appears within a template or templated
    subprogram is the null mapping.
   "

[139:7] In section 8.8 IMPORT Statement, in second sentence of p2,
        after "module procedure interface body", insert " or an
        interface body that appears in a deferred interface block."
        The sentence will then read:

    "This is the default for an interface body that is not a module
     procedure interface body or an interface body that appears in a
     deferred interface block."

[139:14] In sentence 2 of p4, replace "or submodule" with "submodule,
         or an interface body that appears in a deferred interface
         block", such that it now reads:

    "This is the default for a derived-type definition, internal
     subprogram, module procedure interface body, module subprogram,
     submodule, or an interface body that appears in a deferred
     interface block."

Clause 10: Expressions and  assignment
--------------------------------------

[187:4] In, 10.1.12 Constant expression remove " or" from end of item
        (14), add " or" to end of item (15), and then introduce a new
        item for deferred constant.  The lines should now read:

  (14) an ac-do-variable within an array constructor where each
       scalar-int-expr of the corresponding ac-implied-do-control is
       a constant expression,
  (15) a constant expression enclosed in parentheses, or
  (16) a deferred constant,

{This change is possibly not necessary.  Subgroup is not certain.}


Clause 11: Execution control
----------------------------

[225:17+] In section 11.1.11.1 Purpose and form of the SELECT TYPE
          construct, insert entry in R1156 type-guard-stmt:

  "<<or>> CLASS IS ( <deferred-type> ) [ <select-construct-name> ]"

Such that the entire rule becomes:

  "R1156 <type-guard-stmt>
      <<is>> TYPE IS ( <type-spec> ) [ <select-construct-name> ]
      <<or>> CLASS IS ( <derived-type-spec> ) [ <select-construct-name> ]
      <<or>> CLASS IS ( <deferred-type> ) [ <select-construct-name> ]
      <<or>> CLASS DEFAULT [ <select-construct-name> ]"

[226:9+] Add new constraint on R1156 type-guard-statement:

    "C1169b (R1156) <deferred-type> shall specify an extensible type."


Clause 14: Program units
------------------------

[326:12+] In 14.2.1 Module syntax and semantics, add the following
          lines to rule 1408 module-subprogram:

      "<<or>> <templated-function-subprogram>
       <<or>> <templated-subroutine-subprogram>"

  such that the rule now reads:

    "R1408 <module-subprogram>
              <<is>> <function-subprogram>
              <<or>> <subroutine-subprogram>
              <<or>> <separate-module-subprogram>
              <<or>> <templated-function-subprogram>
              <<or>> <templated-subroutine-subprogram>"

[327:2] In section 14.2.2 The USE statement and use association,
        replace ", and namelist groups" with " namelist groups,
        templates, and templated procedures" such that the entire
        sentence now reads:

    "The USE statement provides the means by which a scoping unit
    accesses named data objects, nonintrinsic types, procedures,
    abstract interfaces, generic identifiers, namelist groups,
    templates, and templated procedures in a module."


Clause 15: Procedures
---------------------

In 15.4.2.1 Interfaces and scopes insert a new bullet:

[333:24] Replace ", or" with "," at end of 2nd bullet.
[333:26] Replace "." with ", or" at end of 3rd bullet
[333:26+] Insert new bullet

       "an instantiation of a templated procedure, or a procedure
        accessed from the instantiation of a template."

[334:30+] In section 15.4.3.2 Interface block, in rule 1503
          interface-stmt, add a new line:

       " <<or>> DEFERRED INTERFACE"

such that the rule now reads:

    "R1503 <interface-stmt> <<is>> INTERFACE [ <generic-spec> ]
                            <<or>> ABSTRACT INTERFACE
                            <<or>> DEFERRED INTERFACE"

[335:23+] Introduce new constraint on rule 1503 interface-stmt:

      "C1503b Each <subroutine-name> or <function-name> of an
       <interface-body> that appears in a deferred interface block
       shall be the name of a deferred argument of the scoping unit in
       which the <interface-body> appears."

[336:2] In last sentence of p2, replace "with neither Abstract nor"
        with "without ABSTRACT, DEFERRED, or" such that the sentence
        now reads:

    "An interface block without ABSTRACT, DEFERRED, or a generic
     specification is a specific interface block."

[336:3+] Insert a new paragraph:

    "An interface block introduced by DEFERRED INTERFACE is a deferred
     interface block. An interface body in a deferred interface block
     specifies a deferred procedure."

[340:8+] In 15.4.3.4.5 Restrictions on generic declarations, insert 4
          new paragraphs and a note:


   "The kind of an entity is deferred if the kind depends on the value
    of a deferred argument or depends on a deferred attribute of an
    entity.

    An entity whose kind is deferred only has the same kind as another
    entity if the kind of both entities is declared with syntactically
    equivalent expressions where the declaration is either in the type
    declaration of the entity, or in default kind declaration.

    The rank of an entity is deferred if the rank depends on the value
    of a deferred argument or depends on a deferred attribute of an
    entity.

    An entity whose rank is deferred only has the same rank as another
    entity if:
      - both entities are declared with the RANK clause with
        syntactically equivalent expressions for the rank,
      - both are declared with syntactically equivalent <array-spec>s, or
      - one entity is declared with a RANKOF clause that references
        the other.
      - the two entities have the same rank as some other entity.

  NOTE Some examples of implied-rank entities are shown in the
       following example template. C is declared
       as implied-rank. B is implied-rank because its rank depends on
       the size of the deferred argument S. X, Y and Z are implied-rank
       because their ranks depend on the value of the deferred argument N.

    TEMPLATE EXAMPLE(C, S, N)
      DEFERRED INTEGER, PARAMETER :: C(..) ! implied-shape & implied-rank
      DEFERRED INTEGER, PARAMETER :: S(*), N
      INTEGER, PARAMETER :: B(S) = 1 ! explicit-shape & implied-rank
    CONTAINS
      SUBROUTINE SUB(X)
        INTEGER, RANK(N) :: X ! assumed-shape & implied-rank
        INTEGER :: Y([(i, i = 1, N)]) ! explicit-shape & implied-rank
        INTEGER, RANK(N), ALLOCATABLE :: Z ! deferred-shape & implied-rank
        call sub_explicit(C) ! valid, element order association
        ! call sub_assumed(C) ! invalid, rank expressions don't match
        ! call sub_same_rank(C) ! invalid, rank expressions don't match

        call sub_explicit(X) ! valid, element order association
        ! call sub_assumed(X) ! invalid, rank expressions don't match
        call sub_same_rank(X) ! valid, rank expressions match

        call sub_explicit(Y) ! valid, element order association
        ! call sub_assumed(Y) ! invalid, rank expressions don't match
        ! call sub_same_rank(Y) ! invalid, rank expressions don't match
      END SUBROUTINE
      SUBROUTINE SUB_EXPLICIT(X)
        INTEGER :: X(10)
      END SUBROUTINE
      SUBROUTINE SUB_ASSUMED(X)
        INTEGER :: X(:)
      END SUBROUTINE
      SUBROUTINE SUB_SAME_RANK(X)
        INTEGER, RANK(N) :: X
      END SUBROUTINE
    END TEMPLATE"

[344:19+] In section 15.5.1 Syntax of a procedure reference, append
          two new lines to R1522 procedure-designator:

      "  <<or>> <deferred-proc>
         <<or>> <inline-instantiation>"

  such that the rule now reads:

   "R1522 <procedure-designator> <<is>> <procedure-name>
                                 <<or>> <proc-component-ref>
                                 <<or>> <data-ref> % binding-name
                                 <<or>> <deferred-proc>
                                 <<or>> <inline-instantiation>"

[355:5+] Extend R1524 <actual-arg> with <deferred-proc> and
         <inline-instantiation> such that it now reads:

   "R1524 actual-arg <<is>> <expr>
                     <<or>> <variable>
                     <<or>> <procedure-name>
                     <<or>> <proc-component-ref>
                     <<or>> <conditional-arg>
                     <<or>> <alt-return-spec>
                     <<or>> <deferred-proc>
                     <<or>> <inline-instantiation>"

[363:15+] In section 15.6.2.1 General, append new line to R1530
          prefix-spec:

    " <<or>> TEMPLATE "

such that the entire rule now reads:

      "R1530 prefix-spec <<is>> declaration-type-spec
                         <<or>> ELEMENTAL
                         <<or>> IMPURE
                         <<or>> MODULE
                         <<or>> NON_RECURSIVE
                         <<or>> PURE
                         <<or>> RECURSIVE
                         <<or>> SIMPLE
                         <<or>> TEMPLATE


[363:33+] Insert new constraint on R1530:

     "C1560b (R1530) TEMPLATE shall not appear except in a
              <templated-function-stmt> or a
              <templated-subroutine-stmt>."


[365:11] In section 15.6.2.2 Function subprogram, in C1573, after "in
         the end-function-stmt" insert " in function-subprogram" such
         that the constraint now reads:

     "C1573 (R1536) If a function-name appears in the
      end-function-stmt in a function-subprogram , it shall be
      identical to the function name specified in the function-stmt."

[366:15] In section 15.6.2.3 Subroutine subprogram, in C1576, after
         "in the end-subroutine-stmt" insert " in
         subroutine-subprogram" such that the constraint now reads:

     "C1576 (R1540) If a subroutine-name appears in an
      end-subroutine-stmt in a subroutine-subprogram, it shall be
      identical to the subroutine-name specified in the subprogram's
      subroutine-stmt."

{Note: A rule is referenced in C1573 but not C1576.  This edit makes
this consistent.}

Clause 16: Intrinsic procedures and modules
-------------------------------------------

* 16.9.57 CO_REDUCE(A,OPERATION,...)

[410:24] After second sentence in Arguments paragraph, insert a new
         sentence:

      "It shall not be of a deferred type."

 such that the entire paragraph now reads:

     "A shall not be polymorphic. It shall not be of a type with an
          ultimate component that is allocatable or a pointer. It
          shall not be of a deferred type.  It shall have the same
          shape, type, and type parameter values, in corresponding
          references. It shall not be a coindexed object. It is an
          INTENT (INOUT) argument.  If A is scalar, the computed value
          is the result of the reduction operation of applying
          OPERATION to the values of A in all corresponding
          references. If A is an array, each element of the computed
          value is equal to the result of the reduction operation of
          applying OPERATION to corresponding elements of A in all
          corresponding references.  The computed value is assigned to
          A if no error condition occurs, and either RESULT_IMAGE is
          absent, or the executing image is the one identified by
          RESULT_IMAGE. Otherwise, A becomes undefined."

{Fixed additional spaces introduced by cut-paste.}

[576:17+] Insert new subclause:

     "19.5.1.2b Deferred argument association

         Deferred argument association is described in tt.xx.
     "


Annex A:
--------

* A.2 Processor Dependencies

[597:43] Replace final period "." with semicolon ";".

[597:43+] Append a new bullet in the list of processor dependencies

    * the names of the dummy arguments of a deferred procedure without
      a direct specification and with ultimate specifications that do not
      have the same names for the dummy arguments \ref{Specification
      of deferred procedures}.

===END===