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 * 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 * I⁄O 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
Other proposals without a separate page
A separate set of proposals
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: