ISO/IEC JTC1/SC22/WG5 N2197 Results of WG5 letter ballot 2 on Fortran 2018 interpretations Steve Lionel, May 20, 2022 This is the second set of draft interpretations for Fortran 2018. They have all been approved in a J3 letter ballot. The WG5 ballot opened April 20, 2022 and closed May 20, 2022. Eighteen votes were received by the close of balloting. (Note that for ISO, members are "individual experts" and not representing organizations. This is different from INCITS.) All interpretations passed, with one No vote on F18/019 and comments on 007, 024, 039 and 040. Key for the Result line: Y vote passes unconditionally. C vote passes, subject to minor changes noted below N vote fails. Returned to J3 for further work. F18/ F18/ F18/ F18/ F18/ F18/ F18/ F18/ F18/ F18/ F18/ 007 015 019 023 024 026 027 028 029 030 031 Bader Y Y Y Y Y Y Y Y Y Y Y Bleikamp Y Y Y Y Y Y Y Y Y Y Y Budiardja Y Y Y Y Y Y Y Y Y Y Y Chen Y Y Y Y Y Y Y Y Y Y Y Clune Y Y Y Y Y Y Y Y Y Y Y Cohen Y Y Y Y Y Y Y Y Y Y Y Corbett Y Y N Y Y Y Y Y Y Y Y Friesen Y Y Y Y Y Y Y Y Y Y Y Iwashita Y Y Y Y Y Y Y Y Y Y Y Jibben Y Y Y Y Y Y Y Y Y Y Y Klimowicz Y Y Y Y Y Y Y Y Y Y Y LeAir Y Y Y Y Y Y Y Y Y Y Y Lionel Y Y Y Y Y Y Y Y Y Y Y Menard Y Y Y Y Y Y Y Y Y Y Y Muxworthy C Y Y Y C Y Y Y Y Y Y Reid Y Y Y Y Y Y Y Y Y Y Y Sircombe Y Y Y Y Y Y Y Y Y Y Y Steidel Y Y Y Y Y Y Y Y Y Y Y Result C Y Y Y C Y Y Y Y Y Y F18/ F18/ F18/ F18/ F18/ F18/ F18/ F18/ F18/ F18/ 032 033 034 035 036 037 038 039 040 041 Bader Y Y Y Y Y Y Y Y Y Y Bleikamp Y Y Y Y Y Y Y Y Y Y Budiardja Y Y Y Y Y Y Y Y Y Y Chen Y Y Y Y Y Y Y Y Y Y Clune Y Y Y Y Y Y Y Y Y Y Cohen Y Y Y Y Y Y Y Y Y Y Corbett Y Y Y Y Y Y Y Y Y Y Friesen Y Y Y Y Y Y Y Y Y Y Iwashita Y Y Y Y Y Y Y C C Y Jibben Y Y Y Y Y Y Y Y Y Y Klimowicz Y Y Y Y Y Y Y Y Y Y LeAir Y Y Y Y Y Y Y Y Y Y Lionel Y Y Y Y Y Y Y Y Y Y Menard Y Y Y Y Y Y Y Y Y Y Muxworthy Y Y Y Y Y Y Y Y Y Y Reid Y Y Y Y Y Y Y Y Y Y Sircombe Y Y Y Y Y Y Y Y Y Y Steidel Y Y Y Y Y Y Y Y Y Y Result Y Y Y Y Y Y Y C C Y Status Number Title Comment F18/007 Problems with C_FUNLOC and C_F_PROCPOINTER being PURE Pass F18/015 Example in C.6.8 is wrong Pass F18/019 PURE and default initialization Pass F18/023 CLASS(*) ambiguous operator overloading Comment F18/024 CFI_setpointer with result a deferred length character Pass F18/026 C_SIZEOF argument Pass F18/027 CO_BROADCAST with allocatable component Pass F18/028 Specification inquiry Pass F18/029 Type of main argument of CO_REDUCE Pass F18/030 CO_REDUCE/REDUCE OPERATION with coarray argument Pass F18/031 CO_BROADCAST with polymorphic argument Pass F18/032 CO_BROADCAST and pointer components Pass F18/033 E/EN/ES/D output exponent when w=0 Pass F18/034 Purity of IEEE_GET_FLAG and IEEE_GET_HALTING_MODE Pass F18/035 Defining/referencing a coarray component of a dummy arg Pass F18/036 Array element argument for sequence association Pass F18/037 Locality spec limitations Pass F18/038 SIZE= with no reason Comment F18/039 Corresponding coarrays in recursive procedures Comment F18/040 Allocating dummy arg with a coarray ultimate component Pass F18/041 NULL() passed to assumed-rank dummy Comments -------- F18/007 Muxworthy: Also [xiv:3] after "C_F_POINTER" add "and C_F_PROCPOINTER". F18/019 Corbett: I do not object to the answer. I object to the proposed edit. The text explaining the answer in essence says that if no local or construct variable or named constant is "of a type that has default initialization of a data pointer component to a target any level of component selection" the problems described in the QUESTION portion of the interpretation request cannot arise. I believe this assertion is correct. The proposed edit might ban a bit more than is intended. It clearly suffices to ban the cases that need to be banned. However, it might be read to ban cases that do not need to be banned. Specifically, it might be read as banning type names that name derived types that include default initializations of pointer components to targets. I do not think it does, but I am not sure it does not. A type name can name a local entity that might seem to be subject to the new constraint. However, I do not think that a derived type is "of a type" (it is a type), and therefore, is not subject to the constraint. I find that to be a slender reed. An alternate edit might be C1589a A named local or construct data entity of a pure subprogram shall not be of a {declared} type that has default initialization of a data pointer component to a target at any level of component selection. The word "declared" need not be part of the edit, but I find the sentence easier to read with it. If the the edit is changed as indicated, I will change my answer to "-Y-". If the proposed ban is intended to include type names, I still do not object to the interpretation, but different edits will be needed. (Further discussion in email with Malcolm Cohen disagreeing with Robert Corbett's objections.) F18/024 Muxworthy: At [491:27] also delete "," after "rank". F18/039 and F18/040 Iwashita: I don't think "depth of recursion" is clear. Is it the number of invocations of the recursive procedure in question, or the total number of invocations of all recursive procedures? For example, is the following program conforming? program rec_wrap > if (this_image() =3D=3D 1) then > call wrapper( 3 ) > else > call csub( 3 ) > end if > > contains > recursive subroutine wrapper( n ) > integer :: n > > call csub( n ) > end subroutine wrapper > > recursive subroutine csub ( n ) > integer :: n > real, allocatable :: x(:)[:] > > if ( n =3D=3D 0 ) then > return > end if > > allocate( x(n*100)[*] ) > > if (this_image() =3D=3D 1) then > call wrapper( n - 1 ) > else > call csub( n - 1 ) > end if > > end subroutine > end program >