Eliminate implicit mapping

I don’t personally care one way or another about default implicit mapping, but the tone of the response sucks. Sorry on your behalf.

None of my compilers have a “-u” option. I wonder which one I should buy to become one of the referenced “customers”?


It has been mentioned that the fpm package manager can enforce IMPLICIT NONE as the default if the contributors want to do that. This would “lead the way”, and if it works well, then there would be evidence that the language standard could be changed.

That is the way many changes have been made in the past in fortran (and other languages). Someone implements something, it gets used by programmers, and they can then voice their opinion.

So here is a suggestion. Why don’t you make fpm work that way for some period of time. Say six months, or a year. Then change the default to be consistent with standard fortran for a similar amount of time. Then we can see who complains the most, those who use legacy codes that require extra effort to use, or those who are writing new codes and require portability within the language standard and require extra effort for their codes to work.

So there is the challenge.

Do it, gather statistics, and see what happens. See which group cries the loudest. And then step back and look to see how much all of that turmoil has helped or hurt the language. I think I know the answer to that, but why not look at actual data instead of just opinions?


:slight_smile: it took me a while to figure out what that meant, anyways here is the link where “-u” is applicable, if you want to procure a license.

While the need for implicit none and the implicit save on initialization are a bit quirky, they do not really stop people from getting things done once they know about these quirks.

So I think deprecating them and maybe issuing a warning per default may already be sufficient (Disclaimer: neither have I’ve been involved in the design of compilers nor talked with a large number of stakeholders. So I am aware that my competence is below average in this forum), and the discussions should not become to heated.

I think things like the lack of real generic programming, a standard library or namespace-like structures my be more important for the decision for or against a language applied for a solution.

I am aware and thankful that a lot of people in this forum address these issues and think that from a users perspective the choice of good (i.e., fast stable and to a lare extent standard-conforming) compilers (often free) as well a libraries has never been so good ).

It seems some of those in charge of python agree with you (and J3).

"A series of proposals was previously submitted, for instance, by
proponents of a feature known as static typing, whereby variable
types are manually declared. However, while these changes would
have represented an objective improvement for this specific
sub-community, they were deemed by the council to have an overall
detrimental effect and were therefore rejected."

This is not accurate. The quirks do indeed delay or prevent the evolution of or diminish the adoption of the Fortran language and its ecosystem in quite a few domains.

First consider this comment on another, unrelated thread but where you will notice the Fortran binding to another library has been nearly 3 years in the waiting and yet not completed.

The need for implicit none in interface bodies is one among quite a few factors that delay or prevent the developments of C/Fortran bindings for quite a few useful libraries but it is a crucial one nonetheless. It adds to the pain and the need for implicit none everywhere does tend to become the “final straw” where bindings that are useful to consume solutions in Fortran or use Fortran solutions in other applications are put off indefinitely.

Facilities or features delayed are facilities or features denied, period.

A few developers do end up authoring interfaces without the implicit none and get away with the lurking bugs and errors for a while but circumstances change and with no standard way to address the semantics, the issues surface at the most inopportune time. kernel32.f90 by Intel, Inc. as part of Intel One API for Windows OS is but an example of this: the users of Windows OS who have Intel Fortran can look in <C:\Program Files (x86)\IntelSWTools\compilers_and_libraries\windows\compiler\include> folder of their installation for this. This module has no IMPLICIT statement: over the years, we have had issues with this though most were unrelated to implicit mapping. But several teams started rolling their “own” and without IMPLICIT NONE and did run into errors. Over time, a myriad of problems led teams to migrate away from Fortran. But the “bad experience” with implicit mapping remained with them. Bindings with Windows OS APIs is just one case, there are many others that are dormant or have been discontinued. It all leads to the application of Fortran to be rather unproductive.

The fact is “implicit mapping” in Fortran is

  1. inadequate as a feature,
  2. highly bug-prone as a practice, and
  3. too harmful to the language impression and its standing and reputation.

At this stage, it adds nothing useful to the language, it only hurts.

Moreover the proposal to eliminate implicit mapping as shown in the original post does not require too much time nor effort to implement, it does not come in the way of other advances in the language such as Generics, if anything it will only be beneficial to all future standard language extensions generally.

Additionally the proposal allows \geq 10 years for legacy codebases to adapt which is on top of the nearly 50 years of knowing implicit mapping is not the way to develop codebases.

To eliminate implicit mapping is a “low-hanging fruit”.

It is only the counterarguments in the name of “backwards compatibility” and facetious and fictitious problems of breaking legacy code, almost all of which are likely already “broken” with respect to every standard revision starting ANSI FORTRAN 1966, that get “heated”.


Thanks for your detailed explanation. Although I used Fortran for several years, it has only been in a three/four person team so I do not really have experience in projects with a large teams and lots of external dependencies.
So my statements come from my experience in one medium-sized and more or less self-contained project.

If we can’t get rid of implicit typing/mapping, can we at least have the ability to put implicit none before any USE statements (as in directly after a subroutine, function, or module statement). For Linux/Unix users, writing a bash script that can apply sed to every file in a directory and insert implicit none or your favorite variant of an implicit statement after every subroutine or function statement it finds is fairly trivial.

1 Like

Certain Fortran compilers support automatic generation of C prototypes (see my open issue on compilers supporting generation of C function prototypes which unfortunately received no replies) for Fortran procedures (and interfaces) marked with bind(c). Presumably, this shouldn’t be too hard to implement in a compiler. I guess only few Fortran teams have reached the level of build automation (and influence) to lobby for this.

The other way round, from C functions to Fortran interfaces, is trickier. Personally I’d like to see it solved by the means of C++11 and soon C23 generalized attribute sequences. Using the attribute sequences the compiler could emit the correct Fortran interfaces (including implicit none) when passed the right compiler flag (-fc-prototypes).

The Rcpp package for seamless integration of C++ and R already uses attribute sequences to export C++ functions to R. Here’s one example:

#include <Rcpp.h>
using namespace Rcpp;

// [[Rcpp::export]]
double meanC(NumericVector x) {
  int n = x.size();
  double total = 0;

  for(int i = 0; i < n; ++i) {
    total += x[i];
  return total / n;

Having this built in to the compiler seems like a more robust approach than what third-party tools including SWIG-Fortran and Shroud offer. I will note that these tools go one step further than just interoperable C interface, but are also able to wrap C++ classes and other non-interoperable constructs.

Unfortunately, I’m under the impressions that the Fortran community is too detached from the C and C++ communities to make this a reality. Perhaps my impression is wrong and there are people actively working on this, which would be of great comfort to me. In a few discussions with fellow C++ colleagues, they were pessimistic about this idea receiving any official C++ support (either symbolic from the committee or practical from vendors). Many programming language communities (this Fortran Discourse included) tend to adopt language-centric and exceptionalistic views. There have been dark periods of human history where language-speakers have been prejudiced, banned, and even eliminated. Perhaps the title of this thread would be served better by the word deprecate than eliminate. Interestingly, the use of deprecate to describe obsolescent technology is quite recent.


Is this document covering all issues considered for F202Y or just a subset? I read it and am a bit surprised that the committee has not found any single topic to be “highly desirable”. So if these are really all topics being considered, 4 years after last version was released, the reasons for the committe very existence seem weak.

BTW, of moderate and medium desirability, which one is higher?

I believe it is also true that it would get new customers for some other compilers. So as a member of the committee I can say that this statement does not represent me.


I am afraid the answer to this too shall be a thundering “no” from the influential.

And it’s not just USE, there is also IMPORT which has to precede any IMPLICIT statements. It’s not easy to script a solution and it gets extremely bug-prone to use with real codes.

In the past, several managers / leads have asked me to point to codes or documents or papers, etc. from anyone influential with the committee that advises “go ahead, use implicit mapping”, that it’s a seriously a good way to develop Fortran codes and maintain and extend them. I failed to point any. Can anyone here?

For decades now, everywhere one sees the recommendation to use “implicit none”, the last set of books one team had all advised the same. Naturally the management asks when many other developers complain whenever they need to do anything with Fortran code, why doesn’t the standard make this recommendation the default?

I suppose another way to look at that paper might be in terms of a tacitly conveyed message that, just as with COBOL, there are codebases out there with only a few people who have the knowledgebase to maintain them and who can at anytime join The Great Resignation.

And that for these valuable few, FORTRAN = “implicit mapping”.

And that a change to the standard to be rid of this is too much of a change, it is a major “cultural shock” on top of everything going on everywhere with too many rapid shifts and revolutions.

Thus even if the change to implicit mapping makes no difference in actual practice to them, all their processors will support their codes by default, the very notion of a change on paper will lead to crucial exodus.

Funnily, anyone and everyone who actually foots the bill in one form or the other for these codebases, usually the taxpayer, otherwise the customer, wouldn’t mind at all if those legacy codebases were to move past “the 60s” which arguably represent the intense use of implicit mapping in FORTRAN; by the next decade, the need for IMPLICIT NONE was recognized and MIL standard for FORTRAN even adopted it by 1978.

Not only does FORTRAN = implicit typing for many, it also equals fixed format source files. I find it interesting that those who oppose making implicit typeing at least obsolete in the standard choose to ignore the fact that fixed format source was made obsolete in the Fortran 95 standard (some 25 years ago now if I remember correctly). I don’t remember our sun going supernova, Ragnorok did not descend upon Asgard, and the Four Horsemen of the Apocalypse did not go riding through the Fortran community. Unlike Mr. Spock in the Star Trek movie were he saves Kirk’s life but is exposed to lethal radiation, many on the standards committee seem to think that “The needs of the few or of the one outweigh the needs of the many”

1 Like

Great questions and comments.

No the paper I linked upthread addresses about a third of the 202Y items.

One other review for an additional third of the items is this:

The rest are pending in terms of a documented take on them.

@sblionel, who is also the WG5 convenor, grouped together the items for the subteams to review based on a variety of feedback including those provided by the Community here as collected by @certik in this thread. The currently tabled list is https://j3-fortran.org/doc/year/22/22-176r5.pdf

I simply can’t thank @certik enough for the tremendous Community engagement here and elsewhere. And to @sblionel to facilitate and open up and maintain and drive the various communication and feedback channels with the WG5/J3 working groups. There are all invaluable contributions to Fortran.

As to Fortran 202Y, noticeably Generics is the highly “desired” feature list. Everything else require considerable convincing and very strong “use cases” to move up the “desirable” index!

I’m curious if your managers show the same level of scrutiny also towards other programming languages?

If I take Google’s C++ style guide as an example, they mention quite explicitly:

  • Avoid surprising or dangerous constructs C++ has features that are more surprising or dangerous than one might think at a glance. Some style guide restrictions are in place to prevent falling into these pitfalls. There is a high bar for style guide waivers on such restrictions, because waiving such rules often directly risks compromising program correctness.
  • Avoid constructs that our average C++ programmer would find tricky or hard to maintain C++ has features that may not be generally appropriate because of the complexity they introduce to the code. In widely used code, it may be more acceptable to use trickier language constructs, because any benefits of more complex implementation are multiplied widely by usage, and the cost in understanding the complexity does not need to be paid again when working with new portions of the codebase. When in doubt, waivers to rules of this type can be sought by asking your project leads. This is specifically important for our codebase because code ownership and team membership changes over time: even if everyone that works with some piece of code currently understands it, such understanding is not guaranteed to hold a few years from now.

I’ve read dozens of articles on the internet about avoiding exceptions, avoiding templates, even about avoiding the standard template library… And yet, hundred or even dozens of programming teams continue to use C++. Rightfully so. It’s a great language when used correctly.

That doesn’t mean it’s immune from “legacy” problems too. There was a recent tweet showing a slide from Martin Berzin’s talk at PASC22, which contained the following statement:

Legacy or “clever” C++ is as more of a performance problem as FORTRAN ever was…

You could say we are seeing a revolt against C++ with the appearance of all the new languages aiming to replace C++ including D, Rust, and most recently Carbon. I think the true revolt against Fortran occured already back in the era when MATLAB, C, and other high-level programmers appeared. In essence Fortran was a victim of it’s own success paving the path for other compiled and dynamic languages.

1 Like

The managers themselves usually don’t have to do much of it because the workflows themselves support the scrutiny and review and maintenance and upgrades and rewamp in so many ways even in scientific and technical software. C++ and other C family of codes constantly go through the churn and get refactored and/or retired, things are intense in a way.

Ostensibly there is none of the holding onto some C++98 feature -“over my dead body” type - when C++20 offers better ways to do the same or achieve enhanced overall functionality.

Consider the blog by @jacobwilliams on BISLOC in NASTRAN a while ago:

With other more popular programming languages among the respondents to IEEE Spectrum survey, somehow the equivalent of old codes like BISLOC get revised at a greater frequency and they don’t get so far behind that someone who looks at it later has the same reactions as @jacobwilliams in the above blog!

One vendor I know had to refactor a lot of their extensive GUI code for engineering calculations when C++ standard decided to remove auto_ptr a while ago and end-user custom input/output forms became too difficult to support with newer versions of Microsoft Visual Studio. They just used the occasion to also make a lot of other changes and moved on.

1 Like

I’m glad your organization implements such scrutinizing review and maintenance workflows. Sadly, I don’t think everyone can afford those.

If you’re talking about the reaction it’s a “scene of FORTRAN 66 horrors”, this is just a form of chronocentrism. At the time it was written, the routine may as well have been a programming marvel.

Functions and code sections which get refactored frequently are called “hotspots”. According to works of Adam Tornhill on software evolution these hotspots correlate with defect dense parts. If a code doesn’t get revised it may as well mean the code works.

Of course today it would be unreasonable to expect young programmers to learn F66, just so they could fight their way through NASTRAN. Ultimately this boils down to short-sightedness (also a form of chronocentrism) from the NASTRAN developer teams. Amusingly, MacNeal-Schwendler (now Hexagon AB), the company that commercialized NASTRAN, had an estimated revenue of $230 million USD in 2016. Hexagon AB had a revenue of 4.3 billion € in 2021. I’d be curious to know how much (if any) of these funds ever trickle their way down into Fortran compiler and tool support?

Ansys, another large user of Fortran according to some sources, has a revenue of 1.91 billion US $. It’s a mystery to me how come these and other big companies don’t engage more actively with the Fortran programming language community, unless it all happens covertly via vendors and representatives in the Fortran committees?


It’s much simpler to add -fimplicit-none or equivalent to your build configuration and be done with it. It’s annoying, but it’s a small one-time annoyance.

If you do try to automatically add implicit none statements, you have to include interface blocks (as @FortranFan mentioned) but you don’t have to do subprograms in modules and submodules.

Just for confirmation, does Intel Fortran (ifort) have some option that corresponds to -fimplicit-none? The old thread in the Intel forum below suggests there was none at that time, but I am not sure about the recent ifort versions…

Edit: Sorry, the reply just below suggests there is none even now.