N2231

Comments to N2222, WORK ITEMS from WG5 Meeting 2023

IPSJ/ITSCJ/SC 22/Fortran WG, Japan
May 24, 2024


SC 22/Fortran WG (Fortran WG, Japan's counter organization to WG5)
called on Japanese Fortran users to collect opinions and requests on
the 18 WORK ITEMS selected at the WG5 meeting 2023 (N2222).

The following list shows personal opinions and requests from users in
Japan. And Fortran WG added comments for some of them.


US01: Obsolete default implicit typing (23-177)
===============================================

- If default implicit typing is to be obsoleted, why not also implicit
  typing (by the IMPLICIT statement)? While it is true that default
  implicit tying is often a source of various errors, but exactly the
  same problem occurs with implicit typing.

- Even if it is listed as a obsolecent item in the standard, compiler
  vendors often continue to support it for compatibility. The result is,
  in effect, just procucing more warning messages.

- Note that the implicit typing is used more unconsciously than you
  might think. For example, the following program is syntactically
  correct, but would be an error if the implicit typing were
  abolished. In general, it is not so easy to correct errors caused
  by abolition of implicit typing.

    subroutine sub(a,n)
      real a(n)  ! Here default implicit typing is used for n.
      integer n  ! This type declaration statement is allowed because
                 ! it confirms the implicit typing (see F2028:10.1.11).
      ...

Comment by Fortran WG:
We believe that this problem cannot be solved by the standard alone.
If default implicit typing is to remain de facto, the language
specification should have two modes (implicit typing and implicit none),
and the choice should be made by a compile-time option or a file suffix
for program files. In particular, if the implicit none mode uses a new
file suffix that has not been used before, there is no need to change
the Makefile or build system settings for programs with the current
suffix, even if the compiler is updated.

The same scheme was used in the Fortran 90 era when the default was
switched from fixed form to free form. Since then, the ".f90" suffix
is widely used for Fortran file names. It may be time to switch to a
new suffix.


US07: More rank-independent functionality (23-184r1)
=========================================

- Assumed-rank dummy arguments are difficult to use. For example, even
  a simple array assignment statement must be divided into cases using
  the SELECT RANK syntax.

    subroutine myassign(a, s)
      real, intent(out) :: a(..)      ! assumed-rank array
      real, intent(in) :: s ! scalar variable

      select rank(a)
      rank (0)
        a = s
      rank (1)
        a = s
      rank (2)
        a = s
      rank (3)
        a = s
      end select

    end subroutine myassign

  If we use generic dummy arguments (N2217, 23-244r1) instead of
  assumed-rank arguments, it is not necessary to use the redundant
  case-splitting for formally identical statements.
    
    generic subroutine myassign(a, s)
      real, rank(0:3), intent(out) :: a  ! generic dummy argument
      real, intent(in) :: s              ! scalar variable

      a = s

    end subroutine myassign

  Also in the programming with assumed-rank dummy arguments, reducing
  the burden on users is desirable.


US14: Scoped access to enumeration enumerators (23-197)
==============================================

- The cases that can be saved by the proposed feature are limited to
  name collisions of enumeration enumerators between modules. It
  cannot be used when one is an enumeration enumerator and the other
  is not (e.g., a variable). Also, enumeration enumerators defined in
  modules and hosts are overridden and made invisible when an entity
  with the same name appears in the scope.


US15: Readonly pointers (23-198)
==========================

- "READONLY" is not good. "READ" is a term used for files.


US16: Default kinds (23-199r1)
==============================

- It seems not clear how intrinsic procedures behave when the default
  integer or real is changed. Hopefully it will not have a significant
  impact on compilers and libraries.
  * The argument COUNT of the intrinsic subroutine EVENT_QUERY needs
    to be redefined. Currently, it "shall be an integer scalar with a
    decimal exponent range no smaller than that of default integer."
  * The SIZE, PUT, and GET arguments of the intrinsic subroutine
    RANDOM_SEED are assumed to be of default integer type. 
  * Obsolesent intrinsic functions such as IABS, MAX0, and AINT have
    arguments of default integer or real type.
  * When the argument KIND is omitted in an intrinsic procedure with
    KIND, does it behave as if KIND had the value specified by the
    DEFAULT statement?
    
- The default kind specified in the host scope is inherited in the
  current scope by host association. Therefore, the feature to cancel
  or redefine the specification of the default kind is desirable.
  For example, "DEFAULT NONE", "DEFAULT(REAL = REAL_INIT)", or
  "IMPORT, EXCEPT: DEFAULT".


JP01: Generic Procedures (N2217, 23-244r1)
===================================

- Generic procedure names should be allowed as actual arguments in
  function references and CALL statements. Since a generic procedure
  has the generic name but any specific names, argument passing by
  generic name is required.

Comment by Fortran WG:
We would like to consider this sugestion separately from the proposal
for Generic Procedures. For the generic programming, regardless of
whether a procedure is defined by a generic subprogram or not, the
generic name should be allowed as an actual argument.