Doctor Fortran in "And They're Off!"

Two significant events happened recently in the Fortran world. As I wrote in Doctor Fortran in "DIS, Dat and Doze", the Draft International Standard for Fortran 2018 was submitted for country ballot back in January. There was an eight-week period for possible translations, though I don't know that any occurred, and the ballot officially opened on March 9. Each ISO National Body (country standards committee) gets to vote and can Approve, Approve with Comments or Disapprove. The DIS is available for view at the new J3 web site, - go to Documents > By Year > 2018 > 18-007. 

The US National Body (formally INCITS PL22.3, but we all call it J3) voted at its February meeting to approve the DIS with comments (paper 18-155). Voting runs through June 2, just in time for the next WG5 (international committee) meeting mid-June in Berkeley, California. There, WG5 will consider any comments received and decide which to accept and whether any of the accepted comments constitute technical changes that warrant creating a separate FDIS (Final Draft International Standard), which would require another country ballot (and push the publication date into 2019.) If WG5 decides that any changes are minor, a 30-day ballot is then done to see if countries agree, and if they do, then the FDIS step is skipped and the standard (with minor edits as needed) is published. Yay!

Ok, that's the F2018 news, now on to F202X! As I have written earlier, WG5 ran a survey for many months to solicit user requests for new features in the next Fortran standard revision. The survey received 137 responses, which were collected and organized into WG5 document N2147 (pdf). In my new role as WG5 Convenor I asked each J3 member to send me a list of their top five requests, drawing from N2147 or their own experiences.  These were collated into J3 document 18-122r1 and then distributed to the various J3 subgroups for discussion. Each subgroup then offered their recommendation as to whether or not to do further work on a topic. Some of the requests, upon further analysis, were deemed unworkable, others changed in scope during discussions. Then all J3 members present discussed the proposals and took straw votes as to whether to recommend the features to WG5 - the recommendations paper is 18-156.

This is the very early start at F202X. Other National Bodies will have their own lists of requests, and WG5 members will undoubtedly offer some of their own. My stated goal is to have the feature list nailed down by the end of the August 2019 WG5 meeting in Tokyo, Japan. By keeping the feature list to a manageable size, I hope to keep the process moving forward and have something we can publish by 2022 or 2023 at the latest. Wish us luck!

For more complete information about compiler optimizations, see our Optimization Notice.


Steve Lionel (Ret.)'s picture

There is strong resistance to deleting features from many committee members, including myself. It's ultimately pointless since compilers need to continue supporting deleted features or else risk the wrath of users who just want to compile their existing code. It also creates issues for implementers who no longer have guidance as to how a deleted feature works with remaining features.

We will continue to name features as "obsolescent", though I don't know of any obvious candidates offhand, Statement labels are an intrinsic part of the language and, I think, could never be deleted. Maybe the language could expand the use of named labels but I don't see a lot of benefit for this. I'm not sure what you mean by "implicit SAVE", unless it is for initialized variables. I don't see that as ever changing.

Reducing the language has no practical benefit, and one of the major advantages of the language is the extensive compatibility with "dusty deck" code. I don't want to see that diminished.

Feel free to keep tabs on the web site to read papers and meeting minutes.

Dominik G.'s picture

Thank you for your work and contribution to Fortran for many many years. Are there any plans to delete some features that interfere with modern programming style (such as labels or implicit SAVE)? It irritates me how some programmers mix modern code with gotos, common blocks and labeled format statements. I can't wait to hear more "leaks" on Fortran 2020 development. It's going to be big!

Add a Comment

Have a technical question? Visit our forums. Have site or software product issues? Contact support.