Fortran Wiki
Feature Proposals

Purpose

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.

Proposals

Most Proposals have a separate page. Add your comments there

• Access to the Fortran revision?
• CHAR(string) function
• Allocate-on-assignment for intrinsic string arguments
• Inheritance control for CONTAINed procedures
• Uniform syntax for block constructs
• Named labels
• Generic procedure with subroutines and functions
• Better support for COMMON blocks
• Better support for EQUIVALENCE
• CONSTANT attribute
• INTENT(NONE)
• Typed enumerators
• IO list references in format strings
• Bitwise logical operators
• RANK attribute
• Type coercion
• Assumed-size and assumed-length pointers
• Assumed-size data structures
• Self-defining INTERFACE
• Dynamic Memory Reallocation
• Extended Re-OPEN capabilities
• Multiple allocation, smart pointer
• SEQUENCE types allowed for extensions
• Polymorphism for procedure pointers inside derived types
• Extension to USE statement

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\ ")