At the June 2018 meeting of the International Fortran Standards Committee (WG5) in Berkeley, California, we processed 84 comments received during the ISO ballot of the Draft International Standard (DIS). Many of these comments were editorial in nature, some asked for clarification of technical issues and a couple involved small technical changes. There were enough edits, though, to require creation of a new document referred to as an FDIS (Final Draft International Standard). This will go out for a short ballot, and if all goes well the Fortran 2018 standard should be published by the end of the year. Fingers crossed!
If you want to see all the comments and what we did with them, download ISO document N2153. Most of the columns are self-explanatory, but the leftmost one labeled "MB/NC" may be a bit confusing. The comments are numbered sequentially, generally in page order of the DIS, but some are out of sequence due to the way ISO did the sort. (Feel free to figure out on your own what they did.) The number is preceded by a two-letter code for the country, or "**" if the comment came from ISO itself. The rightmost column contains J3's response (remember that J3, the US committee, is responsible for the text of the standard.) Each response contains a link to the specific J3 paper responding to the comment.
I want to talk about the technical changes as some of them are interesting.
Comment GB020 says, "Specifying a rank [in a SELECT RANK construct] that is not supported by the processor in a is harmless because the statement would not be reached. It should be allowed so that a program can be written that is portable to a processor that does support the rank." The current text in the draft has a constraint saying, "A scalar-int-constant-expr in a select-rank-case-stmt shall be nonnegative and less than or equal to the maximum possible rank of selector." Why is this a problem?
Consider a Fortran compiler that supports more than the standard-specified maximum rank of 15. (Intel Fortran supports 31,for example.) If this constraint remained, you could not write a standard-conforming SELECT RANK construct with a case for ranks greater than 15, even though those cases would never get executed if the compiler supported a lower maximum rank. This being a constraint requires the compiler to diagnose such a case, even though the program might never create an array with more than 15 dimensions.
We agreed that this was unnecessarily harsh and deleted the restriction relating to "maximum possible rank". We then added a note. Unlike other possible technical changes, this didn't require an edit to the Introduction, where all changes from the previous edition are listed, as SELECT RANK is new in Fortran 2018.
Three comments (GB043, GB044 and GB045) took issue with the definition of the new intrinsic RANDOM_INIT, saying it was unclear if a call to RANDOM_INIT in one image had an effect on other images. (Here, "image" is an instance of a program that uses coarrays.) This had special significance for me as I was one of the codevelopers of this feature, and I took on the task of writing the response. It went through several iterations and multiple days of debate, as well as significant changes along the way.
What we ended up with was to state that each image has its own pseudorandom number generator state, and that this state can be changed by calls to RANDOM_INIT or RANDOM_SEED. (Also, obviously, by calls to RANDOM_NUMBER.) We nailed down what was meant by "repeatable" and clarified that a call to RANDOM_INIT on one image did not affect other images, and thus didn't require any synchronization. It also meant that each image that wanted to "initialize" the behavior of RANDOM_NUMBER needed to make its own call to RANDOM_INIT.
Not everyone at the meeting was entirely happy with this resolution, but most agreed that it was a workable definition. Already there were a few murmurs of enhancing RANDOM_INIT in the next standard.
The last technical change came through comment JP079, where they noted that not allowing EXIT in a CHANGE TEAM construct was silly, especially as you could achieve the same effect with a GOTO that branches to the END TEAM statement, which was distasteful. The fix was to allow EXIT in both CHANGE TEAM and CRITICAL constructs, with the effect of "completing" that construct, with an amendment that this is not allowed if the construct in question is nested inside another construct.
We didn't get much time in Berkeley to discuss Fortran 202X, though most seemed to agree that we had made a good start on selecting features through the user survey and discussions at the February J3 meeting. I asked the country representatives to have their National Bodies submit country lists of requests for F202X. We did, however, take "straw polls" on four small features that J3, in February, was uncertain about. Three of them (+= and *= operators, allowing specification statements in some constructs without requiring BLOCK, and initializers/constructors) failed to get sufficient support. One feature for which most said more work should be pursued was allowing arrays and allocatables with coarray components.