To: J3                                                     J3/23-189
From: T. Clune & subgroup generics
Subject: F202Y allow polymorphic deferred type
Date: 2023-June-13

Reference:  23-155

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

Paper 23-155 is the proposed formal syntax for templates in support of
generic programming.  This syntax currently supports almost, but not
quite, all of the proposed use cases in earlier papers.  The notable
exception is the use case to have containers with elements of varying
dynamic type.

Discussion
==========

The current (proposed) syntax for declaring a deferred type in a
template is:

    TYPE, DEFERRED :: T

At least by default, we wish to disallow declarations involving
CLASS(T), as this would _implicitly_ disallow instantiations with
non-extensible types, and in particular intrinsic types.   Likewise,
we would want to disallow type extension ala:

    TYPE, EXTENDS(T) :: EXTENDED_T
       ...
    END TYPE

Such implicit restrictions on instantiation types violate the spirit
of "strong concepts".

One might naively think that the following approach might sidestep the
issue.  The user could define a wrapper type, W as:

    type :: W
       class(My_Type) :: element
    end type

and then pass W as the instantiation parameter for a non-polymorphic
container template.  Unfortunately, this necessitates writing wrapper
procedures for the various accessor procedures for the container to
insert and extract the wrapped element.  And these wrappers would
need to be replicated for each polymorphic use case.  Putting such
wrappers in a template would be elegant, except that one once again
encounter the need to use CLASS(T).


Possible approaches
===================

Subgroup has considered a few approaches to enabling use cases that
appear to demand declarations of CLASS(T).

1. The simplest that we have considered is that of an intrinsic
REQUIREMENT - something like:

    REQUIRES IS_EXTENSIBLE(T)

Use of this requirement would then allow use of both CLASS(T), and
EXTENDS(T), while also disallowing instantiation with an intrinsic
type.  Compilers could generate a very clear message for such
disallowed instantiations.

2. Another approach is to instead somehow specify the desire for
polymorphic support on the INSTANTIATE statement.  The compiler would
then be required to perform various wrapping and unwrapping actions
that are necessitated.  In some ways this would be quite elegant, but
the majority of subgroup is dubious that this approach is truly viable
in the general case.

3. A 3rd approach that is likely to have significant resistance, is to
allow passing non-extensible types to templates that have declarations
such as CLASS(T), but with the understanding that those are simply
translated into TYPE(T) in those instantiations.

Proposal for F202Y
==================

Generics subgroup will explore these solutions and recommend a
specific approach.

===END===