This is entirely a warning without any merit whatsoever in the context of this Discourse that commenced in 2020.
There are essentially 2 utterly detrimental features that have in essence provided no redeeming benefits since 1980 that are being requested to be removed from the language around a decade from now, only because ripping these two from the “root” in the standard and throwing them out is the only path forward other than status quo:
- Remove from the standard implicit mapping, thus implicit none becomes the default in every standard-conforming program unit and interface body
- Remove from the standard implied save, so that an assignment-based definition on a type declaration requires an explicit SAVE attribute specification
Of the two, it’s the first one with a wide impact since every new Fortranner would immediately need to be “lectured” on it and many are “lost” at such a “hello”. There is absolutely no basis for any computing enthusiast in 2032 starting to author in Fortran to be encumbered by FORTRAN’s one error-prone legacy imparted around the 1950s when so much else in the language has been deleted outright.
Regardless, it is only the standard-conforming code that would be affected by the requested changes.
A case in point is NASTRAN’s BISLOC as discussed previously on this site. It is an example of legacy code which is already broken in several ways relative to the standard, yet which can still be used with all the Fortran processors today. Removal of implicit mapping will be the least of its problems - how does one break something that is already broken? That is really bulk of legacy FORTRAN code - already broken vis-a-vis every edition of the standard starting ANSI 1966.
Additionally, with implicit mapping, the codes can easily get back the legacy feature with the introduction of a single line:
implicit integer(i-n), real(a-h,o-z)
Concurrent to all this is the fact most Fortranners don’t know how to conform and the compiler vendors are more than willing to oblige their “indulgence”. The only compulsion anyone ever feels is having to introduce the ridiculous implicit none statement in every module, main program, and interface body so that they don’t come across as daft. Other than that, the FORTRAN codes are ever ready to “start world war III” given their tendency to not conform and the leeway given to processors to do anything with nonconforming code. This is totally different from the Python 2 / 3 situation.
There is in effect no comparison with the above 2 requests for backwardly incompatible feature changes in Fortran with what is being “suffered” by Python 2 apps.