Eliminate implicit mapping

cc: @certik, thank you for bringing attention to @sblionel 's role also as WG5 convenor and the kind of soft influence such a position can bring in terms of vision and direction of Fortran.

To all readers,

The original post in this thread strives hard to differentiate between implicit typing and implicit mapping:

  • implicit typing also encompasses what is possible with explicit IMPLICIT statements, the likes of which can be noticed considerably in codes whose primary development was based majorly on Fortran processors prior to Fortran 90 standard revision.
  • whereas with implicit mapping, the scope is rather narrow, it pertains essentially to that one sentence in the standard that leads to objects whose types are not explicitly declared to have implicit types depending on the first letter of their names.

The proposal tries to make obvious it only addresses the latter i.e., implicit mapping i.e., no change is directed at what is achieved in code via explicit IMPLICIT statements.

Also, note the proposal is not trying to delete anything from the standard, only to change just one long-standing semantics involving implicit mapping. It is a change that only tries to standardize what is a standard coding practice being pursued in practically every program unit by all the Fortranners everywhere. The number of coding instances where the current semantics with implicit mapping is desirable has to be statistically insignificant to be considered as absolute zero.

Moreover the time horizon for change is years away, possibly even two decades out! That is, if any action toward this change is initiated now in which case the earliest it will be considered is with Fortran 202Y for which there is no timeline at the moment. And note the eventual adoption is entirely up to processors, it can be a decade or more later after the date of the standard publication.

Is all this not clear? Can readers please provide their input as to where things are unclear?

The reason also for my plea is because nomenclature is extremely important: if this proposal gets mischaracterized again as deleting of the feature implicit typing which can happen due to mislabeling like in the quoted comment above by @sblionel, it will immediately fail. Hence my request and hope the proposal here not be misrepresented like that.

Ultimately though, this whole thing is an aspect of vision for Fortran, something that would be of constant attention and importance to a WG5 convenor.

The fact is the current semantics with the rules around implicit mapping inflicts damage upon Fortran e.g., in a team I work with in industry, a few missing implicit none statements in a long list of interface blocks (see snippet in original post with foo, bar, etc.) toward interoperability with a library in another processor not only led to disastrous and costly bugs, it also added to negative perception of Fortran and migration away from it.

I reckon there is hardly much of anything positive to be gained by retaining the current implicit mapping rules in the standard for beyond 202X. As the original post mentions, existing codes that prefer such implicit mapping already convey their intent with explicit IMPLICIT statements. IMPLICIT INTEGER(I-N), DOUBLE PRECISION(A-H,O-Z) being ubiquitous in such codes. Thus the risk of breaking existing code is miniscule to zero. More importantly though, should any existing code even “break”, it may even be a welcome event to many users and the gatekeepers of such codes!

Considering all of above, it comes down to this:

Is it possible at all to envision that by year 20XY (say 2040), the Fortran standard would advance to the point a Fortranner can expect a standard-conforming program unit and an interface body to have *implicit none* by default, independent of any processor options?

Is such a small aspect of a vision unacceptable and/or objectionable to you as a member of the Fortran Community? If yes, can you please post your reasons and objections here?

2 Likes