Proposal List for 202X

[certik]

Here is the list of issues approved by WG5 to go into 202X:

• UK01 - Extend procedure C_F_POINTER to allow a Fortran array pointer to have lower bounds other than 1.
• US01 - Allow much longer statement lines and overall statement length.
• US02 - Require the processor to report cases where over-long lines or statements result in lost information.
• SPLIT intrinsic #187 US03 - SPLIT string intrinsic (original proposal was to keep all module intrinsics from the withdrawn Part 2 (ISO_VARYING_STRINGS).
• Degree trigonometric functions #164 US04 - Trig functions with arguments in degrees and arc versions with results in degrees.
• US05 - Trig functions with arguments implicitly scaled by PI.
• US06 - SELECTED_LOGICAL_KIND to return a KIND of logical based on its minimum storage size.
• US07 - Additional named constants, LOGICAL8, LOGICAL16, LOGICAL32, LOGICAL64, in ISO_FORTRAN_ENV to specify KINDS supported for type LOGICAL.
• REAL16 proposal #13 US08 - Additional named constant, REAL16, in ISO_FORTRAN_ENV to specify whether the processor supports a 16-bit REAL KIND.
• US09 - Intrinsics for converting between C strings and Fortran strings.
• US10 - AT format editing specifier. Has the effect of TRIM on the corresponding character list item before output.
• US11 - Control over leading zeros in output of REAL values.
• US12 - Allow an array of a type that has an allocatable coarray component.
• Edits for Put with Notify #20 US13 - Syntax and semantics for a "Put with Notify" operation.
• Auto-allocating processor messages #160 US14 - Allow deferred-length character variables in more locations, including as actual arguments corresponding to IOMSG and ERRMSG arguments for similar variables in specifiers. Also allow for internal I/O.
• US15 Simple procedures #161 US15 - SIMPLE procedures. A form of Super-Pure that disallows references to global data.
• US16 TYPEOF and CLASSOF #158 US16 - TYPEOF and CLASSOF type declarations to indicate the object being declared has the same type/class as another object. Useful to ensure a local variable in a procedure has the same type as a dummy argument, or that two dummy arguments have the same type.
• Rank-agnostic array element and section denotation #157 US17 - Syntax to specify an element or section of an array with arbitrary rank.
• Rank-agnostic array element and section denotation #157 US18 - Syntax for generic specification of rank and bounds of an object.
• Protected Components #156 Protected attribute for variables in derived types #16 US19 - Protected components.
• Add reductions to DO CONCURRENT #17 US20 - Reduction specifier for DO CONCURRENT.
• Enumeration Type #11 US21 - Typed enumerators.
• Conditional Expressions #183 US22 - Conditional expressions. (alternatively: Short-circuiting logical expressions #19 US26 - Short-circuit logical operators.)
• Standardizing use of BOZ constants #18 US23 - Enhancements to BOZ constants.
• Allowing "const" on pointed to data #5 US27 - Syntax to specify that the target of a dummy argument pointer is not to be changed (INTENT applies to the pointer, not its target)

The list is described in the document N2165 US Feature list proposals for F202X (PL22.3) as available from https://wg5-fortran.org/documents.html, but unfortunately the link is dead. We also found the list in the minutes N2169 Minutes of the August 2019 Meeting in Tokyo available from https://wg5-fortran.org/f202x.html. Just in case, I am attaching the N2169 document to this issue, so that it does not get lost.

Once all such ideas are fully developed and passed by the J3 and WG5 Committees, then the 202X standard will get out, and we will work on 202Y.

In order to speed up the 202X release as well as to ensure that the community agrees with the proposals that the committee passes, I encourage wide community participation in the proposals for these features.

ISO-IECJTC1-SC22-WG5_N2169_Minutes_of_the_August_2019_Meeting_in_Tokyo.txt

[certik]

As a community, I suggest we provide use cases (code) and syntax that we like. I can then ensure that the Committee's final proposals will work with the use cases that the community wants.

[zjibben]

I found a copy of N2165 on my hard drive:

ISO-IECJTC1-SC22-WG5_N2165_US_Feature_list_proposals_for_F202X.txt

There are a few extra details that aren't in the minutes.

[zjibben]

Here is the list of items, with added issue numbers where I found them. Some work needs to be done yet to add issues or find ones I missed, then making sure the background papers are listed in the related issues. We might also update the issue names to include the USxx item number. Feel free to edit this comment to add new info.

Update (Ondrej): I moved the list to the issue description above to make it more easier to see.

[shahmoradi]

@certik Ondrej, I am not sure where my requests for enhancements should go on the J3 repository. So I am going to list it here and hopefully you will know much better or help realize where I should submit them:

1. Coarray slicing (equivalent of MPI_gather)

   real :: co_Vector[*]
   real, allocatable :: LocalVector(:)
   ...
   LocalVector = co_Vector[ 1 : num_images() ]
   ...

   As far as I am aware, coarray slicing is currently not supported in Fortran 2018. This feature, however, is highly desired for writing a more concise code and potentially enabling more compiler optimization. The equivalent standard-conforming code would be:

   integer :: i
   real :: co_Vector[*]
   real, allocatable :: LocalVector(:)
   ...
   allocate( LocalVector(1 : num_images()) )
   do i = 1, num_images()
       LocalVector(i) = co_Vector[i]
   end do
   ...

2. the ability to use dummy optional arguments when not present in a procedure:

   function runSampler(chainSize)
       integer, intent(in), optional :: chainSize
       if (.not.present(chainSize)) chainSize = 10000
       ...

   This is similar to the RFE by Curcic et al, so I won't explain it further here.

3. standardized support for a minimal healthy subset of the C/Fortran preprocessing features. preprocessors are essential for writing scalable code and many compilers are fully or partially support some level of preprocessing. C has this as part of the language. Adding preprocessors to Fortran would ensure that the community's use of preprocessors is more disciplined and supported by the language standard.

4. further support for template metaprogramming. I know that this is already a highly popular RFE. So I just suffice to mention my strong support for it.

[certik]

@shahmoradi I moved your comment to #174, let's discuss there. This issue #162 is for proposals that are already approved for 202X.

[h-vetinari]

Is there a good place to track the status/timeline of 202x? The WG5 page says:

Development Schedule

This is the current development schedule (see N2135) for Fortran 202x. See the Glossary for definitions of terms.

• Started planning further revision 2017-06
• Choose issues that need attention 2018-06
• Preliminary choice of technical content 2019-08
• Final choice of technical content 2020-06
• CD constructed 2021-06
• CD ballot initiated 2021-07

though the document from which this originates seems to be from 2017. I also looked at https://fortran-lang.org/ and https://fortran-lang.discourse.group/.

[certik]

@h-vetinari that's a good question for the WG5 Convenor. @sblionel what is the best place to track the status/timeline for 202X?

[sblionel]

Ah, I see I haven't updated that page. The current schedule is at https://wg5-fortran.org/N2151-N2200/N2185.txt We may end up 2-3 months late with the final steps, but we're on track to publish in the second half of 2023. The DIS is currently being constructed and should be available for ballot soon.