# 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

Other proposals without a separate page

• C_ASSOCIATED should be defined as PURE. (This may just be an oversight.)

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