# Eliminate implicit mapping **URL:** \ **Category:** Help\ **Created:** [July 30, 2021, 11:03pm UTC](https://fortran-lang.discourse.group/t/eliminate-implicit-mapping/1612 "2021-07-30T23:03:17Z")\ **Posts on this page:** 14\ **Page:** 5
**Author:** ![ivanpribec](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ivanpribec/32/3290_2.png) [@ivanpribec](https://fortran-lang.discourse.group/u/ivanpribec)\ **Post date:** [July 24, 2022, 10:44pm UTC](https://fortran-lang.discourse.group/t/eliminate-implicit-mapping/1612/90 "2022-07-24T22:44:00Z")
I’m glad your organization implements such scrutinizing review and maintenance workflows. Sadly, I don’t think everyone can afford those. > [@FortranFan](#): > > 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! If you’re talking about the reaction it’s a “scene of FORTRAN 66 horrors”, this is just a form of [chronocentrism](https://en.wikipedia.org/wiki/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](https://www.adamtornhill.com/articles/software-revolution/part1/index.html) 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](https://en.wikipedia.org/wiki/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? ---
**Author:** ![ashe](https://avatars.discourse-cdn.com/v4/letter/a/ce73a5/32.png) [@ashe](https://fortran-lang.discourse.group/u/ashe)\ **Post date:** [July 24, 2022, 11:30pm UTC](https://fortran-lang.discourse.group/t/eliminate-implicit-mapping/1612/91 "2022-07-24T23:30:32Z")
> [@rwmsu](#): > > 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). 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. ---
**Author:** ![septc](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/septc/32/77_2.png) [@septc](https://fortran-lang.discourse.group/u/septc)\ **Post date:** [July 25, 2022, 12:19am UTC](https://fortran-lang.discourse.group/t/eliminate-implicit-mapping/1612/92 "2022-07-25T00:19:01Z")
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… > **[enforce implicit none](https://community.intel.com/t5/Intel-Fortran-Compiler/enforce-implicit-none/td-p/892888)** > > I was wondering if there is a method of enforcing "implicit none" with some compiler option. I am already using /warn:declarations but I would like the compiler to stop with an error when an undeclared variable is encounterd. Is there a compiler... Edit: Sorry, the reply just below suggests there is none even now. ---
**Author:** ![rwmsu](https://avatars.discourse-cdn.com/v4/letter/r/48db29/32.png) [@rwmsu](https://fortran-lang.discourse.group/u/rwmsu)\ **Post date:** [July 25, 2022, 12:22am UTC](https://fortran-lang.discourse.group/t/eliminate-implicit-mapping/1612/93 "2022-07-25T00:22:14Z")
I’m perfectly aware of the issues with adding implicit none to existing codes. Even though I mentioned modules my main focus is on legacy Fortran (fixed format .f files). Adding -fimplicit-none or -u might work for gfortran or NAG but I don’t think there is an equivalent flag for Intel Ifort. You can force ifort to give you warnings but only in combination with -warn. I rarely use gfortran and have only used NAG once a long time ago. The issue is not that there exists compiler flags to turn on implicit none, the issue is the polarity of those flags should be reversed. If you tried to get me to use (let alone buy) any code that still used implicit typeing I would tell you to take a hike. It’s dangerous, it has been demonstrated for countless decades to be one of the major sources of bugs in Fortran code, and it is universally accepted as both poor software engineering and lets be honest, lazy programming. ---
**Author:** ![sblionel](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/sblionel/32/853_2.png) [@sblionel](https://fortran-lang.discourse.group/u/sblionel)\ **Post date:** [July 25, 2022, 12:36am UTC](https://fortran-lang.discourse.group/t/eliminate-implicit-mapping/1612/94 "2022-07-25T00:36:15Z")
> [@septc](#): > > 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 Intel Fortran, like Compaq and DEC Fortran for decades, definitely has such an option. It is called `-warn declarations`, and requires all entities to be explicitly typed, otherwise you get a warning. There is a separate option that turns warnings into errors. Fortran has NEVER deleted a feature without making it obsolescent for at least one revision - we’re not going to start now. I have been lobbying to make implicit typing obsolescent, and think this has a good chance of happening, just as was done for COMMON, EQUIVALENCE and fixed-form source. Over time, this will accomplish what some folk here want, reducing the use of implicit typing in new or revised codes. ---
**Author:** ![septc](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/septc/32/77_2.png) [@septc](https://fortran-lang.discourse.group/u/septc)\ **Post date:** [July 25, 2022, 12:47am UTC](https://fortran-lang.discourse.group/t/eliminate-implicit-mapping/1612/95 "2022-07-25T00:47:42Z")
Thanks very much for the additional info! However…, as far as I understand from the linked thread above, `-warn declarations` does not correspond to `-fimplicit-none`, and so the OP (in that thread) wishes the latter? Or possibly, is there a way to selectively turn `-warn declarations` only to an error (without affecting other warning options)? I think it would be useful if an exact counterpart to `-fimplicit-none` is available in all the major compilers (particularly Intel Fortran), but if not, the “use -u” argument linked above ([https://j3-fortran.org/doc/year/22/22-182.txt](https://j3-fortran.org/doc/year/22/22-182.txt)) does not seem to make sense (to me). ---
**Author:** ![rwmsu](https://avatars.discourse-cdn.com/v4/letter/r/48db29/32.png) [@rwmsu](https://fortran-lang.discourse.group/u/rwmsu)\ **Post date:** [July 25, 2022, 1:01am UTC](https://fortran-lang.discourse.group/t/eliminate-implicit-mapping/1612/96 "2022-07-25T01:01:55Z")
Thanks, Steve. I can live with making implicit none obsolete for now. One question though. Any chance of eliminating some of the annoying requirements such as the placement of implicit none after USE I mentioned up thread along with the need for IMPORT in interfaces. I still don’t understand why thats needed but would appreciate an explaination if you have one. I think its due to how the concept of scoping units are handled in existing compilers but that is just a guess. ---
**Author:** ![sblionel](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/sblionel/32/853_2.png) [@sblionel](https://fortran-lang.discourse.group/u/sblionel)\ **Post date:** [July 25, 2022, 1:12am UTC](https://fortran-lang.discourse.group/t/eliminate-implicit-mapping/1612/97 "2022-07-25T01:12:52Z")
> [@rwmsu](#): > > Any chance of eliminating some of the annoying requirements such as the placement of implicit none after USE. Offhand, I don’t know what prompted that requirement nor what might break if it was relaxed. Is it really a problem? As for the need for IMPORT in interfaces, this happened before my time on the committee, but we did talk about it at last week’s meeting, and I was told that there was a heated discussion on the topic of whether host association works inside of an interface body back in the Fortran 90 days. The view that won was that an interface body was a “window” into the external procedure, and that the body should replicate the declarations in the external procedure. IMPORT was added later to make it easier - I wrote a lot about this in [Domestic or Imported? - Doctor Fortran (stevelionel.com)](https://stevelionel.com/drfortran/2006/10/05/domestic-or-imported/) Interestingly, the reason this topic resurfaced was that the new generic template feature being designed DOES do host association in its interface blocks, for good reasons. ---
**Author:** ![Beliavsky](https://avatars.discourse-cdn.com/v4/letter/b/ba8739/32.png) [@Beliavsky](https://fortran-lang.discourse.group/u/Beliavsky)\ **Post date:** [July 25, 2022, 1:41am UTC](https://fortran-lang.discourse.group/t/eliminate-implicit-mapping/1612/98 "2022-07-25T01:41:26Z")
> [@rwmsu](#): > > 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). This is > > > Currently \`implicit none\` must appear after \`use\` statements in a module or main… program. Could this restriction be removed? As long as Fortran has implicit typing, \`implicit none\` should appear at the beginning of a main program or module. It would convenient if you could just put it on the second line of source files and look for it there, instead of looking for it under any number of \`use\` statements. > > I would not call this a big improvement, but unless it is difficult for compiler writers to implement, it may be worth doing. ---
**Author:** ![FortranFan](https://avatars.discourse-cdn.com/v4/letter/f/96bed5/32.png) [@FortranFan](https://fortran-lang.discourse.group/u/FortranFan)\ **Post date:** [July 25, 2022, 1:52am UTC](https://fortran-lang.discourse.group/t/eliminate-implicit-mapping/1612/99 "2022-07-25T01:52:28Z")
> [@sblionel](#): > > … I have been lobbying to make implicit typing obsolescent, and think this has a good chance of happening … Admittedly it portends well for Fortran to read this. However I just don’t see how it is possible to “make implicit typing obsolescent” without eliminating implicit mapping. Say implicit typing is made obsolescent in a Fortran revision 2XYZ. Immediately the use of `implicit none` becomes obsolescent that a conforming processor then will try to detect and report as far as it can do so by reference to any of numbered rules and constraints. However the `implicit mapping` may or may not be obsolescent; it will depend on the rest of the semantics: - say `implicit mapping` remains: the obsolescence of `implicit none` then will make matters absolutely worse. - But now if `implicit mapping` is too made obsolescent, then one needs something in its place that is not obsolescent, some another semantics to dictate the mapping. One simply cannot make something obsolescent without a replacement facility. But then the replacement to the `implicit mapping` is exactly what is proposed in the original post, " **If a mapping is not specified for a letter, the default for a program unit or an interface body shall be NULL, and the default for a BLOCK construct, internal subprogram, or module subprogram is the mapping in the host scoping unit"** So I think there is a real catch-22 here, I do not think `implicit typing` can be made obsolescent first. The real need is for `implicit mapping` to be tackled first and that is what this proposal is all about. Once this is done, then `implicit typing` can be made obsolescent. And if better counsel prevails with Fortran, `implicit typing` can be deleted too in a future revision! There are situations that call for \*_exceptions_ to the best of rules and procedures, however well intended and comprehensive. The case with `implicit mapping` is one such exception, I am presently convinced. Either make that exception, or get into rather knotty situations that then force the status quo with implicit typing. ---
**Author:** ![RonShepard](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)\ **Post date:** [July 25, 2022, 8:08am UTC](https://fortran-lang.discourse.group/t/eliminate-implicit-mapping/1612/100 "2022-07-25T08:08:10Z")
Ok, so let me get this straight. First you guys want to eliminate the default implicit typing that is the current standard. This will require people to add something like `implicit real(a-h,o-z), integer(i-n)` to all of the legacy codes that they use. Then you want to eliminate implicit typing altogether. This would require those programmers who just added the implicit statements to go back into their legacy codes, remove the implicit statements and explicitly type all of the entities in their codes. And they would need to do this to all the legacy code they use that already had implicit statements in it too. And I should point out, that this still does not solve the basic problem with legacy codes in the first place, namely that they already exist in books, on servers, and by individuals sharing the codes among themselves in their original forms. Those codes will then need to be changed, rather drastically I would say, in order to use them. And you think this will be good for the language? Getting jerked around by the standards committee twice, within a relatively short time period (say one or two revisions)? First requiring them to fiddle around with the legacy codes, then declaring that what was just required of them is now obsolete and they must undo what they did and do something else even more drastic. How can that kind of plan possibly be good for the language? If this questionable plan is enacted, should the standards committee also provide tools to the programmers to make these changes automatically? By the nature of legacy codes, this is not something that will be done once to a given code, it will need to be done by each programmer every time the original code is accessed, from now to eternity. Every time the original code is typed in from a book, or downloaded from some server somewhere, or sent from one person to another by email, this code transformation will be required. ---
**Author:** ![sblionel](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/sblionel/32/853_2.png) [@sblionel](https://fortran-lang.discourse.group/u/sblionel)\ **Post date:** [July 25, 2022, 1:57pm UTC](https://fortran-lang.discourse.group/t/eliminate-implicit-mapping/1612/101 "2022-07-25T13:57:32Z")
> [@FortranFan](#): > > However I just don’t see how it is possible to “make implicit typing obsolescent” without eliminating implicit mapping. > > Say implicit typing is made obsolescent in a Fortran revision 2XYZ. Immediately the use of `implicit none` becomes obsolescent that a conforming processor then will try to detect and report as far as it can do so by reference to any of numbered rules and constraints. However the `implicit mapping` may or may not be obsolescent; it will depend on the rest of the semantics: I’m not sure where this is coming from. If implicit mapping is obsolescent, then that includes `IMPLICIT` other than `IMPLICIT NONE`. Compilers would be required to have the ability to diagnose uses of variables or functions whose type was not explicitly declared, as well as uses of the `IMPLICIT` statement that supplied mapping to initial letters. I agree it would make no sense to do this and still allow the `IMPLICIT` statement to specify mapping. ---
**Author:** ![FortranFan](https://avatars.discourse-cdn.com/v4/letter/f/96bed5/32.png) [@FortranFan](https://fortran-lang.discourse.group/u/FortranFan)\ **Post date:** [July 25, 2022, 2:16pm UTC](https://fortran-lang.discourse.group/t/eliminate-implicit-mapping/1612/102 "2022-07-25T14:16:56Z")
> [@RonShepard](#): > > Ok, so let me get this straight. First you guys want to eliminate the default implicit typing that is the current standard … Let me make it absolutely straight: **The scope of the proposal in the original post in this thread is limited to implicit mapping only.** Effectively it makes implicit none the default and that’s it - no other changes at this stage, as I mention ad infinitum. Anything else such as making implicit typing obsolescent, while a worthy goal, seems a bridge too far, too disruptive at this stage. ---
**Author:** ![Beliavsky](https://avatars.discourse-cdn.com/v4/letter/b/ba8739/32.png) [@Beliavsky](https://fortran-lang.discourse.group/u/Beliavsky)\ **Post date:** [July 25, 2022, 4:14pm UTC](https://fortran-lang.discourse.group/t/eliminate-implicit-mapping/1612/103 "2022-07-25T16:14:39Z")
Designating something obsolescent can be done for two reasons: (1) warn that the feature may be deleted in a later standard (2) express the view of the committee that a feature should not be used I think it’s fine to say that implicit typing, as exemplified by code such as `implicit real(a-h,o-z), integer(i-n)` is obsolescent for reason (2) above, but as others have said, actually removing it would be too disruptive. Maybe features satisfying (2) but not (1) (they are bad but will remain in Fortran) can be designated **deplorable** 🙂 . More seriously, if the committee did make implicit typing obsolescent, perhaps it could say that it does not expect to remove it in the future (although one committee cannot bind the hands of a future one). [Previous page](https://fortran-lang.discourse.group/t/eliminate-implicit-mapping/1612.md?page=4)