To: J3                                                     J3/22-182
From: Malcolm Cohen
Subject: DATA review of F202y items from 22-176r4
Date: 2022-July-21


1. Introduction

This is an initial review of the suggested DATA items in 22-176r4.
Further investigation may alter the conclusions.


2. Review

Item: Desirability, Scope, Effort

1. Delete default implicit typing
     Undesirable, Unacceptable, Immaterial
   Doing this would drive away existing customers.
   Those who need this know how to type -u.

2. Delete implied SAVE for initialized variables
    "It's called 'use the assignment statement'."
    Low desirability, Unacceptable, Immaterial
    Silent change of semantics is unacceptable.

3. Namespace for modules
    The proposals here are multitudinous; much of the functionality is
    already provided by existing syntax, the main thing that looks useful
    would be a syntax for "remote access" to module entities, e.g.
    "modulename % entityname". Not sure % is the best thing for this.
Medium desirability, Limited scope, Fairly easy.

4. More assumed-rank functionality
    The proposals here are not particularly inspiring, but subgroup agrees
    that more could be done to make assumed-rank more useful inside of
    Fortran. Rank-agnostic subscripting may play a part here.
    More investigation required.
Medium desirability, Moderate scope, May not be too hard.

5. Obsolete (not delete) default implicit typing
    As this cannot feasibly be deleted (compilers will need to support it
    for the foreseeable future) there seems little point in obsoleting it.
    Users or companies that want explicit typing can simply mandate use of
    the -u option.
Low desirability, Limited scope, Fairly easy.

6. Pointer intent
    Subgroup agrees that some form of read-only pointers is desirable.
    Some work has already been done on this. The simplest reasonable
    solution should be sought.
Medium desirability, Hopefully limited scope, Probably easy.

7. bf16 and fp16
    Fortran has had the ability to access a provided bf16 or fp16 since
    1991. We do not agree that support should be required.
N/A. n/a N/A

8. Somehow fix the issue of mixed precision
    Silent change of semantics would be unacceptable.
Undesirable. N/A. Difficult.

9. Augumented assignment
    This has been suggested before, and been found to be controversial
    and/or not as useful as envisaged. 19-111r1 has some discussion of
    the pros and cons of this kind of thing.
Low desirability. Moderate scope. Fairly difficult.

10. Enable Polymorphic Outputs from Pure
    This bears further investigation to establish the scope. Is it just
    the final procedures, or is there more about type-bound procedures?
Interesting desirability. Limited scope. Probably easy.
    Perhaps a PURE attribute on a type?

11. Revisit strings
    There would be value in re-examining the issues, but many proposals
    in the past tended to suggest intrinsics for what would be very
    simple expressions already. It should though be possible to add a
    small number of useful intrinsics that don't introduce too much
    complexity. More investigation required.
Moderate desirability. Limited scope. Need to keep simple.

12. Default values for absent arguments
    This should be fairly easy to get right.
Moderate desirability. Limited scope. Easy.

13. Simple functions in constant expressions
Low desirability. Large scope. Difficult.

14. Non-extensible extensible derived type
    We even have a keyword already that we could use for this.
Low-medium desirability. Limited scope. Easy.

15. "Proper" enumeration types
    Subgroup agrees that additional functionality for our existing
    enumeration types would be a good idea. There is a clear path to
    using our existing types in a "scoped" fashion. Care needs to be
    taken to avoid an overly-complicated facility.
Medium desirability. Medium scope. Variable complexity.
    "Scoped" should be considered in conjunction with the possible
    "remote access" of item 3 above.
    Keeping this simple would keep the desirability high, getting
    overly complicated would make it less desirable as well as a lot
    more work.

16. Review all the restrictions on polymorphic entities and remove as
    many as is reasonable.

    It is impossible to guess the scope of this without more information
    on what the proposer has in mind. We await with bated breath.

JOR/14... this appears to be a /Data proposal.
    We agree that something like this would be used if it were available.
Medium desirability. Medium scope. Moderate complexity.

===END===