To: J3                                                     J3/24-155
From: Malcolm Cohen
Subject: Recommendation on User Defined Procedures In Constant Expressions
Date: 2024-June-26
References: 24-104.


This paper presents the /DATA subgroup recommendations on the proposed
User Defined Procedures In Constant Expressions, paper 24-104.

Re 2.1... Complicated Definition of Named Constants

Subgroup disagrees that

    simple function real_kind_with_fallback(p, fallback) result(k)
      integer, intent(in) :: p, fallback
      integer :: k
      k = selected_real_kind(p)
      if (k <= 0) k = fallback
    end function
    integer, parameter :: wp = real_kind_with_fallback( &
    30, selected_real_kind(15))

is a significant improvement over

    integer,parameter :: dp = selected_real_kind(15)
    integer,parameter :: qp = selected_real_kind(30)
    integer,parameter :: wp = ( qp>0 ? qp : dp )

Re 2.2...Constants of Derived Types With Private Components

Subgroup considers that the way the example uses private components is
not hugely convincing as a use case.

Re 2.3...Constants of Derived Types With Allocatable Components

Subgroup considers that allocation is an inherently runtime thing,
and that it is always inappropriate to do allocation at compile time.

Both 2.2 and 2.3 appear to display design choices for those derived types
that deliberately prevent the usage being attempted. For example, 2.2 need
not make the component private, and 2.3 could use pointer components and
assignment overloading instead of an allocatable component.

Finally, execution of arbitrary remote user-defined procedures at compile
time is a heavy burden on the processor. That C++ has chosen to inflict
that burden on its processors does not necessarily lessen the impact on a
Fortran processor.

Therefore, subgroup contends that this feature is at best very poor value
for its cost, and at worst is undesirable. We recommend not pursuing this
feature at this time.

===END===