To: J3                                                     J3/25-191r2
From: Malcolm Cohen
Subject: US16 Default kinds, formal requirements, specs, syntax
Date: 2025-November-21
Reference: 23-199r1, 25-191r1


1. Introduction

See 23-199r1 for an introduction to this feature.
This paper has the formal requirements and specifications as approved by
INCITS/Fortran at meeting 237.
It also has syntax, but that has not yet been discussed.

See 25-191 (previous revision) for additional discussion and background.


2. Requirements (approved)

R1. That the default kind for each intrinsic data-type can be controlled
    by specifications within the source code of the program.

R2. In principle, each program unit should be able to control this.

R3. In principle, a nested scoping unit should inherit the default kind
    settings from its host.

Note: These requirements leave a lot unspecified, including whether the
      settings can be overridden in nested scoping units. Those details
      will be addressed in the specifications.

Aspiration: The feature should be as simple and easy to use as possible.

R4. Specifying the default kind shall not affect entities with specified
    kind type parameters. That includes variables or components whose
    declaration includes the KIND= specifier, and literal constants that
    have an underscore and kind-param appended.

R5. That the rules for the obsolete storage association feature will apply
    to what would have been the default kinds when the feature is not being
    used.

R6. Changing the default kind for REAL shall change the default kind for
    COMPLEX accordingly.

3. Potential terminology for specific types.

3.1 REAL type

What is currently termed "default real kind"
can be "single precision real kind".
Or just "single precision" for short.

What is currently double precision real kind is unchanged.

3.2 INTEGER type

What is currently termed "default integer kind"
can be "default range integer kind" (shortened to "default range"),
or perhaps "standard integer kind".

Standard integer kind has storage size equal to that of single
precision real kind (that is basically its defining characteristic,
other than being the default when there is no user-specified default).


3.3 LOGICAL type

What is current termed "default logical kind"
could be "default size logical kind"
or simply "standard logical kind".

Then, standard logical kind is the kind with storage size equal to that
of single precision real kind.


3.4 CHARACTER type

There are a handful of places where CHARACTER values/variables are
required to be "default kind". These are most in interactions with the
operating system, e.g. FILE= in OPEN and the COMMAND in GET_COMMAND and
EXECUTE_COMMAND_LINE.

That suggests using the term "system character kind" for default default
character.


4. Other technical issues

Discussion of these issues appears in 25-191r1, and is deleted here,
giving only the results.

4.1 DOUBLE PRECISION type specifier and the D exponent letter

On balance, it seems least surprising to have DOUBLE PRECISION unaffected
by any change to what default REAL is. This will be spelled out in the
specifications.

4.2-4.3 Specific intrinsic functions

On balance, the implementation effort to implement passing all the specific
intrinsic functions as actual arguments for all possible kinds seems too
much for what is, after all, an obsolescent feature.

4.4 Generic intrinsic procedures

A straw vote was taken at meeting 237 as follows:
    (a) change most generic intrinsics to return specified default kind?
    (b) have generic intrinsics not be affected by default kind spec?
    (c) undecided.
Result (a) 9 (b) 1 (c) 5.

Therefore most generic intrinsics will return specified default kind.

4.5 Input/output

In the interests of keeping the implementation burden low, there will be no
change to input/output specifiers.

4.6 User-defined derived-type input/output procedures

In the interests of keeping the implementation burden low, there will be no
change to defined input/output procedure.

4.7 Scoping

A straw vote was taken at meeting 237:
    (a) As per IMPLICIT, but disallow overriding?
    (b) Exactly the same scoping rules as IMPLICIT.
    (u) Undecided.
Result: (a) 3 (b) 7 (u) 6.

Therefore the same scoping rules as IMPLICIT will be adopted.

4,8 Use association

R7. It should be possible, with appropriate syntax, to import the default
    kind settings from a module.

4.9 Named constants for the old default real etc.

A straw vote was taken at meeting 237 on whether to add named constants to
ISO_FORTRAN_ENV for the old default kinds, with spelling approximately:

    SINGLE_PRECISION    - kind of single precision real
    DOUBLE_PRECISION    - kind of double precision real
    STANDARD_INTEGER    - kind of default range integer
    STANDARD_LOGICAL    - kind of default size logical
    SYSTEM_CHARACTER    - kind of system character

The results of the straw vote were
    (add these named constants) 15
    (no not add these) 0
    (undecided) 2

Therefore these names will be added.


5. Specifications (approved)

S1. That the default kind of integer, real, logical, and character shall be
    specifiable in a program unit.

S2. That "default complex kind" shall continue to be be the same as default
    real kind, and shall not be separately specifiable.

S3. That the storage-association effects of default real be associated with
    "single precision real kind".

Note: This in effect suggests that "default real kind" be changed to
      "single precision real kind" in storage association contexts, and
      left as "default real kind" in other contexts.

S4. That the DOUBLE PRECISION type specifier and the D exponent letter are
    unaffected by this feature, viz specify the same kind as without it.

S5. That specific intrinsic procedures are unaffected by this feature.

That means:
  i. Specific intrinsic functions that accept or return default real in
     F2023 shall accept and return single precision real in F2028.
     Specific intrinsic functions that accept or return double precision in
     F2023 shall accept and return standard double precision kind in F2028.
     Specific intrinsic functions that accept or return default complex in
     F2023 shall accept and return single precision complex in F2028.
 ii. Specific intrinsic functions that accept or return default integer in
     F2023 shall accept and return default range integer in F2028.
iii. Specific intrinsic functions that accept or return default character
     in F2023 shall accept and return system character in F2028.

S6a. Generic intrinsic procedures that accept or return default kind (of
     some type) in F2023 shall accept or return specified default kind in
     F2028, except for special cases such as EXECUTE_COMMAND_LINE.

S7. That input/output specifiers are unaffected by this feature.

S9. That the arguments of defined input/output procedures shall be default
    range integer and system character, as they are now.

S10. That the default kinds can be specified by a constant expression that
     does not depend on the properties of a default kind, as long as that
     default is not specified after such usage.

S11. The default kinds can be specified in a program unit, interface body.
     or nested subprogram, but not in any other kind of scoping unit. They
     apply to all nested scoping units other than interface bodies.

S12. The default kind settings can be imported from a single module into a
     program unit, interface body, or nested subprogram. After such an
     import, they shall not also be specified locally.

S13. Named constants for the old standard default kinds shall be added to
     ISO_FORTRAN_ENV.


6. Example with illustrative syntax

This is taken from the original proposal, and is clearly incomplete.

    PROGRAM example
        DEFAULT(REAL=SELECTED_REAL_KIND(30))
        REAL :: x = 1.23456789012345678901234567890
        PRINT '(F0.29)',x
    END PROGRAM

That would be expected to print a reasonably accurate approximation to the
literal constant.


7. Proposed syntax (not discussed)

Y1. The form of the new statement shall be
    default-kind-stmt is
        DEFAULT KIND ( default-kind-spec-list )
    default-kind-spec is
        intrinsic-type-name = int-constant-expr
    intrinsic-type-name is
        REAL or INTEGER or LOGICAL or CHARACTER
{The BNF intrinsic-type-name is not used at present, but could be confusing
 in that COMPLEX is missing (DOUBLE PRECISION is not an intrinsic type name
 just a keyword in a type specifier). Maybe we should call this
    basic-intrinsic-type-name
 instead.}

A possible alternative syntax would be
        DEFAULT KIND :: default-kind-spec-list

Y2. The int-constant-expr in a default-kind-spec shall not depend on a
    property of the default kind of a type, unless that type has its
    default kind previously specified in the scoping unit or its default
    kind is not specified in the scoping unit.

Y3. A default-kind-stmt shall appear after any USE statement, but before
    any IMPLICIT statement.

Y4. Constraint: The same intrinsic-type-name in a default-kind-stmt shall
                not appear more than once in a scoping unit.

Y5. More than one default-kind-stmt may appear, subject to Y3.

Y6. A default-kind-stmt shall appear only in the specification part of a
    program unit or interface body, and applies to all nested scoping units
    other than interface bodies.
{This would mean there is no overriding of a host-specified default kind.}

ALTERNATIVE Y6 (see straw vote in 4.7):

Y6. A default-kind-stmt shall appear only in the specification part of a
    program unit, interface body, or nested subprogram, and applies to all
    nested scoping units other than interface bodies.


Y7. The default kinds can be imported from a single module with a USE
    statement that has the ", DEFAULT_KINDS" clause. Only one such import
    is permitted, and if used, no default-kind-stmt shall appear in the
    scoping unit.
    The ", DEFAULT_KINDS" clause is only permitted in a scoping unit that
    would otherwise be permitted to have a default-kind-stmt.

    This changes the beginning of the USE statement syntax from
        USE [ [ , module-nature ] :: ]
    to
        USE [ [ , module-nature ] [ , DEFAULT_KINDS ] :: ]

Y8. The default kind when no default kind specification is in effect is:
        default real kind = single precision real kind
        default integer kind = default range integer kind
        default logical kind = default size logical kind
        default character kind = system character kind

OPTIONAL: (See 4.9)

Y9. ISO_FORTRAN_ENV shall have named constants as follows:
        SINGLE_PRECISION    - kind of single precision real
        DOUBLE_PRECISION    - kind of double precision real
        STANDARD_RANGE_INT  - kind of default range integer
        STANDARD_SIZE_LOGICAL - kind of default size logical
        SYSTEM_CHAR_KIND    - kind of system character

===END===