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.