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
- inadequate as a feature,
- highly bug-prone as a practice, and
- 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”.