Open certik opened 4 years ago
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.
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.
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.
@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:
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
...
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.
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.
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.
@shahmoradi I moved your comment to #174, let's discuss there. This issue #162 is for proposals that are already approved for 202X.
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/.
@h-vetinari that's a good question for the WG5 Convenor. @sblionel what is the best place to track the status/timeline for 202X?
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.
Here is the list of issues approved by WG5 to go into 202X:
187 US03 - SPLIT string intrinsic (original proposal was to keep all module intrinsics from the withdrawn Part 2 (ISO_VARYING_STRINGS).
164 US04 - Trig functions with arguments in degrees and arc versions with results in degrees.
13 US08 - Additional named constant, REAL16, in ISO_FORTRAN_ENV to specify whether the processor supports a 16-bit REAL KIND.
20 US13 - Syntax and semantics for a "Put with Notify" operation.
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.
161 US15 - SIMPLE procedures. A form of Super-Pure that disallows references to global data.
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.
157 US17 - Syntax to specify an element or section of an array with arbitrary rank.
157 US18 - Syntax for generic specification of rank and bounds of an object.
156 #16 US19 - Protected components.
17 US20 - Reduction specifier for DO CONCURRENT.
11 US21 - Typed enumerators.
183 US22 - Conditional expressions. (alternatively: #19 US26 - Short-circuit logical operators.)
18 US23 - Enhancements to BOZ constants.
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