I request readers to note the amount of new code being written now in modern Fortran or even being contemplated, let along considered, is for all practical purposes the equivalent of zero even if it occasionally rises above the numerical epsilon. This is also a fact in technical computing domains that should otherwise be a forte for Fortran. An indirect measure of this is the latest programming language survey from IEEE Spectrum where Fortran is virtually a dead language with a score around 0.59 compared to Python at 100 and C++ at about 88. IEEE Spectrum practically covers the interests of the largest group of engineers interested in coding floating-point calculations on modern computers, something that really took off only when IBM FORTRAN I first introduced REAL type in a higher-level programming language back in the 1950s:
Whilst Fortran has many, many challenges that also require big language evolution around Generics and the handling of error termination of programs initiated by a Fortran processor or by means other than a Fortran processor, particularly with FUNCTION subprograms, a couple of significant irritants with newcomers are indeed implicit mapping and implied SAVE.
The nasty, nasty semantics in the Fortran standard with implicit mapping and implied SAVE do indeed lead to the proverbial straw that broke the camel’s back with many newcomers not bothering further with Fortran and especially with managers and powers-that-be and decision makers resolving to not select Fortran as the language of choice in even scientific and technical computing components in new application development. The effects are all there to see in the above IEEE Spectrum link.
To dismiss these two detrimental features as effectively “mere straw” and thus informing all newcomers to simply put up with them forever only further hurts the language.
Moreover the resolution toward these two issues are really low-hanging fruits that can be plucked toward a clean up in this language for the sake of posterity. They don’t require much of any effort on the part of standard bearers nor the compiler implementors nor the users. And the timeline involved is a decade plus to perhaps 15-20 year window considering the earliest the changes can now be considered is 203X standard revision which is already far more than about the ten years Python people extended to Python 2 → 3 migration. Not to forget Python rose to the very top among the practitioners following such a backwardly incompatible transition - so what lesson does Python’s brave move impart here?
There is really no need to make a big deal about this in terms of community resistance to the request, particularly if you are using implicit none everywhere already. This is not a “battle”, for heaven’s sake, least of all the “wrong battle”, these can addressed quickly, taken care of, and the language can move on to the big challenges. Even silence will be preferable than to blow it up as a “battle”.
The “old codes” are already broken in several other ways with respect of the current standard, or not getting compiled at all in any statistically significant circumstances by any modern processors, or already employing implicit statements fully, or at times partially with a nonstandard IMPLICIT REAL*8(A-H, O-Z) one when they could have made it not a concern at all for anyone else with the full IMPLICIT REAL*8(A-H, O-Z), INTEGER(I-N) statement. But even otherwise, every Fortran processor, nonconforming as they usually are “off the shelf”, will support all such “old codes”. There is no risk whatsoever nor any downside.
To hold the language hostage for future practitioners for the indulgences and indolence of the past practitioners and current maintainers is simply not right.