Fortran Wiki
Feature Proposals


Fortran Standards development has a history of controversy, and new standards often seem to have “half baked” implementations. Unfortunately, the committee-driven standards development often does a poor job of meeting the interests of the user community. If we can develop proposals for new language features and illustrate a common interest, there is a reasonable chance of incorporating them into the next Fortran standards revision.


Most Proposals have a separate page. Add your comments there

Other proposals without a separate page

  • C_ASSOCIATED should be defined as PURE. (This may just be an oversight.)
  • Simplify function/procedure definition by allowing full specification of the input/output parameters in the argument list without having to do part of the specification again (= partial redundancy) in the body (resembling local vars). This is the way it works for almost every other prog. language so Fortran should support this too. Currently this is also very verbose this should be made more succint (on par with most mainstream languages) e.g. via sensible defaults for the possible options (this is already partly so) or maybe even better via type inference like in F# or Scala.

A separate set of proposals

A PDF containing a separate set of proposals can be found here. Alternatively a XHTML version (simpler formatting than the PDF) can be found here

Extensions that should be avoided

These are extensions already implemented by some compilers, but have negative consequences that make them undesirable features.

  • Merging undelimited string literals (as in C). This just allows errors from a missing comma to go unnoticed, and is totally unnecessary because Fortran already supports breaking long strings across multiple lines.

  • Silently casting between logical and integer types. Again, the potential for missed errors outweigh the benefits of allowing sloppy coding.

  • Overloading logical operators as bitwise operators. Some compilers support this and the previous extension, leading to many opportunities for ambiguity.

  • Using period as an alias for the percent character in selecting derived-type members. The period produces a cleaner code appearance, but can also result in ambiguities.

  • Support for C-style backslash escape sequences. This can be useful, but is not compatible with standard Fortran. Instead, this should be supported via an intrinsic string function. For example: C_escape("Hello\ World\ ")