Trying to standardize a de facto standard practice with a targeted timeline which is a couple of decades away is absolutely in no way “pushing for breaking changes”.
One can understand the argument circa 1990 when the upcoming standard revision was about to be published (it was in 1991).
But not 30 years later for a change that will likely see the light of the day in year 2041 i.e., about 50 years after IMPLICIT NONE became officially part of the standard.
It is about time some actual evidence is presented to the Fortran Community, I feel.
I too have considerable work experience that has offered me the opportunity to study and review many codebases in legacy FORTRAN. I’m yet to come across a single one in actual use that did not intend to use either IMPLICIT NONE or IMPLICIT INTEGER(I-N), xx(A-H,O-Z). Meaning there has not been a single program thus far that intentionally employed the implicit mapping semantics.
So if there are actual programs out there that use the implicit mapping aspect, the Community deserves to know of them and some details around them. The argument, oh those are commercial, proprietary, etc. should be considered wholly inadequate any longer.
Should be such FORTRAN code which can “break” at all - though I highly doubt it - chances are of some connection with an operating nuclear plant and/or nuclear/energy lab. Much of other information around such a facility in likely already in the public domain that any notion of secrecy surrounding their FORTRAN code will be ludicrous. Instead, the code itself is likely to be in the public domain also. This Community, but more importantly tax payers too, then need to know about the use and workflow with such codes. If those codes are run with processors that have already not seen an upgrade with 20 or 30 years - another likely scenario!! - and if they are unlikely to see another upgrade due to a host of reasons (e.g., Fukishima effect), it should be a strong consideration.
So my simple point is: can the Community get to actual names and superficial details on codes that can break?
Saying “This would break a very large number of existing programs and would lead to a revolt by users” without evidence is of no help.
I am personally aware of no such code either.
But even if some codes exist, it doesn’t matter because compilers will always be able to compile them, irrespective of what the standard says. As they should.
I provided an outline above how we should proceed on this.
@FortranFan is there any other issue to resolve?
A key issue to address is a fundamental one about the relevance of the standard.
Either the standard means something, or it does not. There is no in-between.
Sure one can take actions extraneously to the standard and avoid landmines like with fpm and LFortran or other processor options, etc. But those are all besides the point.
When a standard fails to standardize what is a standard practice among an overwhelming majority of practitioners, it fails entirely to meet the common good.
If this is allowed to persist, there shall remain no raison d'etre for Fortran, really.
I disagree very strongly with this. These people who can’t make the most trivial changes to their code (e.g., add a single compiler flag or add an implicit double precision statement) are then going to move away from Fortran when they are told a decade in advance that they’ll need to do those things?
Why are these people allowed to have an iron grip around the throat of Fortran? It doesn’t make sense to me. These people are not the future. Why are they being allowed to hold up progress? Implicit none needs to be the default. This is 50 year old nonsense that gets shoved in the face of Every Single new Fortran programmer. It is a constant source of confusion and errors year after year, decade after decade.
It’s time to move on. Bold ideas are needed to save Fortran. If we can’t get this one simple thing fixed, it does not bode well for the future.
P.S. I manage Fortran software that is used by hundreds of people at NASA (and was just named NASA Software of the Year). Sometimes things break when I update the compiler. Sometimes it’s a compiler bug, sometimes it’s because the compiler is a little more strict about not allowing slightly non-standard things. When this happens, I fix the problems and move on. Sure, sometimes I delay updating the compiler because of these issues. But the idea that I would never update compilers or move away from Fortran because something changed in a compiler update it absurd to me.
While I agree that most of them likely wouldn’t move away due to this change, doesn’t this argument work the other way as well? Who moved away from Fortran because they had to (and they don’t really have to, it’s a recommendation) type implicit none, or use a compiler flag to do it for them?
I do think this would be a net positive change for the language in the long run. I think @certik outlined the way to go: user adoption first (we have that), tools adoption second (we will have that), and finally the standard. And that’s how we should do it for everything else about the language (new syntax, intrinsics, etc.).
Exactly!
And, from my experience so far at the committee, it seems the people there are very reasonable to standardize an already existing practice.
But leading the effort should come from us, not the committee. As it should for every feature. And we are now doing exactly that.
Agree entirely.
With IMPLICIT NONE, the matter needs to seriously advance beyond preaching to the choir.
The fact is many Fortran practitioners have been keen on IMPLICIT NONE since around the time of FORTRAN 77 {ANSI X3.9 1978). MIL-STD 1753 introduced IMPLICIT NONE as far back as 1978. And many Fortran processors have since supported IMPLICIT NONE as an extension to FORTRAN 77, this was present all through 1980s. There have been good code with teams in industry I have worked with that were developed using Microsoft FORTRAN 3.x compiler circa mid-1980s that employed IMPLICIT NONE exclusively. Articles around the development and conflicts during the work toward the eventual Fortran 90 standard indicate IMPLICIT NONE was an easier introduction to that revision.
Out in the public domain, an overwhelming approval has long existed existed for the practice of IMPLICIT NONE as the default in every program unit and interface body.
The holdouts are strangely anonymous but seemingly impervious to everything has gone on since around 1978. Why would anything change with such codes anytime in the future then?
To give such holdout anonymous codebases a higher precedence all these decades later, even with year 2041 in mind, is only running an Animal Farm, some are being treated as more equal than others.
That’s not how it works.
Readers can take note of the proverb/poem, “For want of a Nail.”
Not making IMPLICIT NONE the default is a crucial little detail that makes Fortran “nor here, nor there” when it comes to being serious about type handling. This has indeed led to many a bad first impression of Fortran and which, as the saying goes, has lasted with peers and colleagues I know. Moreover, mistakes have occurred, particularly with interface bodies (see the original post with what can happen with a long chain of interface blocks), that have led to teams I know not bothering with writing Fortran interfaces to production libraries that are based on processors other than Fortran. This has catalyzed the move away from Fortran.
A lot has been lost when it comes to Fortran being seen in the past tense as the lingua franca of scientific computing.
Like in that poem I quote above, the root causes all come down to little details that didn’t get the attention and importance they deserved along the way: IMPLICIT NONE not being the default is among them.
Year 2041, as the Golden Jubilee of Fortran 90, looks like a good target date to finally introduce such a change, it will be a great way to celebrate that milestone revision.
@FortranFan why don’t you help us with this PR:
and it can happen in 2021!
As I have written before, the first step is to make implicit typing obsolescent. (Implicit interfaces too?) That will have several effects. First, books on Fortran will stop treating it as a first-class feature. Second, users who ask for standards checking (or who use compilers that default to it) will see diagnostics and be encouraged to update their code. Some shops have coding practices that explicitly discourage use of obsolescent features.
This is the Fortran way of nudging people towards better practice.
Why does implicit typing have to be obsolescent before we can make it not the default? I mean, I’m in favor of making it obsolescent, but why do we have to do that before we can say implicit none is the default, you don’t have to bother typing it anymore?
Personally I would not want fpm or any compiler to make implicit none a default, because I may later use a code with a compiler that does not make it the default, thus reverting to implicit typing. Or if I publish the code, another user may do this. Implicit none should appear in the main program and at the beginning of a module. I’d like a compiler that warns about the absence of implicit none, which I can turn into an error.
If in Fortran 204x implicit typing were removed and implicit none became redundant, I assume that implicit none statement would still be allowed but have no effect.
Changing the language so that implicit typing is not the default would break untold thousands of programs that were valid according to the previous standard. That’s not the Fortran way.
We have changed defaults in cases where only non-conforming programs would notice, such as making procedures RECURSIVE by default in F2018. We’re also willing to specify behavior that was previously left unspecified.
The Fortran approach is to mark a feature as obsolescent.
-fimplicit-none for gfortran
-u -warn errors for ifort
-u for nagfor
-fimplicit-none-type-always for flang
-eI for Cray/HPE ftn
Please add any that I missed.
Ah, yes, I hadn’t quite remembered that. However, it would break them in a way that I (and I would hope others) would find acceptable; the compiler will tell you, not produce a differently behaving program. It feels to me a bit like mom finally threatening to ground you unless you clean up your room. Sure it’s a chore and nobody really wants to do it, but everybody knows they should and understands the benefits of doing so. This would just finally give them the excuse they need (or need to present to management). Besides, as has been repeated ad-nauseum here and other places, the compilers will to continue to support it anyway, probably just with a new (or possibly even existing, i.e. -dusty) flag.
I deleted a few posts that were off-topic and/or inappropriate. Please stay on topic, respectful, and refrain from discouraging the discussion.
I take no offense with spirited discussions! 
In my mind, there is no more pressing matter for this community than to rejuvenate Fortran and to get people wanting to use it to write new codes. I think we all want that right? A very, very, very small part of that massive task is to hide the 50 year old nonsense. But it’s a very important part. All of us here are used to typing “implicit none” all over the place like some kind of cargo cult programming handed down by our ancestors. But it is a profoundly weird and dumb feature that causes confusion and errors and ill will, year after year after year, decade after decade after decade. (and guess what…implicit typing isn’t the only thing that falls in this category). Enough is enough. It’s time to make the kids clean their rooms.
Oops if i also caused any offense, I apologize! None was intended!