To: J3                                                     J3/22-181
From: R. Bleikamp & JoR
Subject: JoR review of F202y items from 22-176r3
Date: 2022-July-20

#Reference:

Here are JoR's initial thoughts/recommendations for the proposed new
JoR work items for Fortran 202y as described in 22-176r3.  Some
include initial thoughts on what the feature might look like, in order
to solicit feedback from the committee members.

--------------------
Defered to other subgroups:  JoR would prefer another subgroup adopt
these items.
  (JoR) 2. Better error handling:  Big, unspecified.  Should be done,
           by a new subgroup.
  (JoR) 15. Review all the restrictions on polymorphic entities and
            remove as many as is reasonable.  JoR recommends DATA
            subgroup adopt this item.

--------------------
Recommended items:
  Medium items:
    cpp: likely approach: examine existing cpp like support, adopt a
         viable subset, make it Fortran friendly w.r.t. fixed/free
         source form, Fortran comments, continuation lines, ...
         support #include, #ifdef, #if.  It is a companion processor,
         off by default.  Processor dependent: how to enable it.
         NOT Optional. Required to be available to be F202y compliant.
         Relatively high priority.  Likely a new part 2 of 1539.

  Small items:
    change f.p. model to be IEEE 754, so examples/descriptions match
    common HW.  Desirable. Easy. Low priority.

    Go thru all the processor dependencies in Annex A: we should do
    this as a low priority item.  Easy, if we only choose the easy
    ones.

    immutable values.  assign once at runtime, and then can't be
    changed.  low cost, useful, medium priority.

    program specified default kinds for constants and intrinsic types.
    Desirable, low to medium effort.  Medium priority.

--------------------
Undecided:
  scan/prefix sum:  JoR needs help to understand typical usage, ...

  Disallow use of specific new F202y features in a program unit that
  uses any deprecated/deleted features. This is a way to discourage
  users from using obsolescent features (such as fixed form source).
  You would get a "non-conforming" error message (maybe a warning,
  maybe fatal).
  Subgroup is uncertain about the desirability of this feature.
  Small effort.  Strong committe support might change our mind.

  scan clause for do concurrent reduce: TBD, no opinion yet.


--------------------
Not recommended:
  Surprising results for UBOUND and LBOUND when argument has zero
  extent. Low priority, JoR is leaning towords dropping this feature.
  A compelling use case would change our mind.

  log2: just log2, or survey math.h and see what other base 2
  intrinsics are missing from fortran. Easy to do, We would like a
  compelling use case (HPC related) before we would tackle this
  feature.

  intrinsic to return the name of your caller. JoR decided not to
  pursue this.  Again, a compelling use case might change our mind.
  Overhead and possibly requiring debugging info is a concern.  Seems
  like a companion processor (debugger) can do this.:

  ASSERTs. May be simple to do yourself if we have cpp.
  JoR sees little value in this if we have cpp.

  Deprecate D format edit descriptor: serves no useful purpose, but
  no big reason to deprecate it.  Low priority.  Easy?

  constexpr: JoR needs to research this more, but it seems un-fortran
  like.  JoR would like to see a compelling use case.
  Also seems expensive to implement?