ISO published the latest revision of the Fortran standard, Fortran 2023, on November 17. We’ve been working on this for five years, and it brings many new features, expansions of existing features, and fixes to text that was either wrong, ambiguous, or failed to define correct behavior. You can read John Reid’s excellent summary of The New Features of Fortran 2023, but I’ll highlight a few of them here.

  • Past revisions have increased the number of continuation lines allowed, but we keep getting complaints that it’s not enough. Moreover, many people want to write source lines longer than 132 columns in free form, and that value hasn’t changed at all since Fortran 90. Now, a free-form source line may be up to 10,000 characters in length and the limit on continuation lines has been removed entirely, being replaced by a total statement size limit of one million characters. (This is primarily to benefit machine-generated source.) The continuation line and total statement size limit also applies to fixed-form source, which continues to be an obsolescent feature.
  • Conditional expressions provide the ability to selectively evaluate one of two or more expressions based on a value. The syntax for this varies across various languages, but after intense debate, we selected something closely resembling many other languages using the ‘?’ character. An example would be value = ( a>0.0 ? a : 0.0) . An important distinction is that ? is not an operator, but part of the syntax including the enclosing parentheses. Another is that, unlike other expressions in which operands can be evaluated in any order and to any degree of completeness. only the “true” case of a conditional expression is evaluated.
  • A conditional argument looks like a conditional expression, but it selects an actual argument, which could be a variable, exactly as if that argument was specified directly. An additional feature allows you to select .nil. as an indicator that an optional argument is not present.
  • The C interoperability procedure C_F_POINTER now allows you to specify lower bounds for the created pointer.
  • A new AT format edit descriptor automatically trims trailing whitespace from character values, and, answering many years of complaints and requests, it is now possible to control whether the “optional” leading zero in output of real values is included.
  • A number of features helpful in enabling generic programming were added, such as typeof() and classof(), and a new syntax for using integer arrays for specifying subscripts, ranks and bounds of an array.
  • “True” enumerator types that aren’t just another way of saying PARAMETER, with features to make them interoperable with C enums.
  • A new reduction specifier for DO CONCURRENT.

There’s lots more, and compilers are already adding support for some of these. Meanwhile, the committee has been taking user requests to make a list of features and changes for the next revision, which we informally call Fortran 202Y. Generic programming has been under development for five years now, and the model looks quite useful. We’re also going to revisit the notion of standardized preprocessor syntax. Unlike the previous attempt known as CoCo, what we want to do is standardize existing practice that resembles C preprocessing, with an aim to preserving compatibility, though we are finding interesting differences across the various implementations.

If you want to read the new standard, ISO will be happy to sell you a copy. The committee itself uses an “interpretation reference document”, standing document 007 on the J3 web site. At the time I post this, the latest 007 document 23-007r1 is close, but not quite the same as the published standard. There will eventually be a newer one, probably called 24-007.


These are all significant, much-needed enhancements, Steve. Thank you and the committee for your hard work toward publishing F23. There is still a long list that I would wish to see in Fortran. I know that some are being worked out, and some are less obvious and known that nobody in the committee seems to advocate or consider. A prominent example is multiline string literal constants (without the need for the string line continuation &&), which are very similar in functionality to Python docstrings. That may not seem such a critical feature for an HPC language. But we live in an era when pure traditional HPC is only a small fraction of today’s supercomputer power consumption. Fortran needs to adapt to the needs of the new data-driven era, which often requires heavy use of strings and text manipulations. Implementing docstrings in the language should not be a major challenge for the committee and compiler developers. I’d suggest using backtick (either one, or three like Python) for docstrings in Fortran because single and double quotes are already taken. But anything that does the job would be great. Fortran standard cycles are pretty sparse for today’s world. Each new release is almost equivalent to a new stage in people’s careers. Missing the opportunity to add a simple feature to the language is almost equivalent to one generation missing the opportunity to use it in their work. I very much hope to see docstrings in Fortran before 2030.

Sorry, I misread Amir’s comment. I agree that docstrings would be very useful as well. We lean very heavily on the Doxygen format, but it would also be great if they were incorporated into the language syntax.

Write Your Comments

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Subscribe to Doctor Fortran

Subscribe to Doctor Fortran