“GOD IS REAL, unless declared INTEGER.” That’s the only Fortran joke I know, the basis of which is one of the oldest (mis)features in the language, implicit typing. As it has been since The FORTRAN Automatic Coding System for the IBM 704 (1956), variables whose names start with the letters I through N are implicitly INTEGER, all others are implicitly REAL. (In ur-Fortran, these were called “fixed point” and “floating point”.) The earliest Fortran didn’t have type declarations at all, nor the IMPLICIT statement. I think it safe to say that no other Fortran feature has caused programmers more trouble, yet it remains a “first-class” feature today. Some people want to change that, though the approaches vary. Let’s explore.
The original Fortran went even further regarding inferring attributes from names. Functions had names of four to seven characters, ending with the letter F, and if they were integer (fixed point) functions, the names started with the letter X; thankfully, that went away with FORTRAN 66. But while other ancient features such as fixed-form source and EQUIVALENCE have been declared obsolescent, default implicit typing is still with us. For decades, programmers relied on implicit typing, saving them from having to explicitly declare their variables and function return types. For those same decades, other programmers got tripped up when, unawares, they created an integer-valued function with a name starting with, say R, and took advantage of another Fortran (mis)feature, implicit interface. Over the years, the language added IMPLICIT NONE (first formalized in MIL-STD-1753) to force programmers to declare types, and now there is IMPLICIT NONE (EXTERNAL), blocking implicit interfaces, but these “blade guards” must be explicitly (!) added by the programmer (or in many cases, forced on by a compiler switch.) Wouldn’t it be better if default implicit typing went away entirely? That’s a proposal put forward in Fortran Proposals – Eliminate implicit typing) (This site collects suggestions for future language features, where they can be discussed by anyone interested. It isn’t sponsored by the Fortran standards committee, but we will use it as one of many sources in our planning for future revisions.)
Both in Fortran Proposals and in Fortran Discourse) (a more general place to discuss Fortran) I have argued that simply dropping a decades-old feature is not “the Fortran way”. I suggested instead that default implicit typing, and maybe the IMPLICIT statement (not IMPLICIT NONE) be declared obsolescent, the way fixed-form source is already. What this would do is 1) stop (or at least slow) implicit typing from being taught as a language feature, 2) cause compilers to issue diagnostics if the feature were used (may require the user to ask for such diagnostics), and thus 3) discourage its use in new code. Once deemed obsolescent, it could be deleted from a later revision, but we rarely delete features, given that compilers will continue to support them anyway, and, speaking for myself only, I am against deleting features as that means you no longer have text in the standard explaining how the feature works with the rest of the language.
An objection to making implicit typing obsolescent is that it doesn’t require compilers to flag such usage by default, only that the capability be there (usually via a compiler option checking for standards compliance.) My counter to that is that the first thing most programmers would do is turn off this feature, and if they couldn’t, they’d use a different compiler. Another suggestion adds a third category for “retired” features, presumably with default reporting, but this seems to me to be an unnecessary complication.
What do you think of obsoleting or deleting implicit typing? Read the discussions I linked and let me know in the comments.
IMPLICIT …
Should be supported such that old/original Fortran programs will compile. An information message (warning) could be issued should implicit types be in effect (with option switch to suppress warning). Let’s not break old (historical) code
Making a feature obsolescent doesn’t break code. Even deleting a feature, practically speaking, doesn’t break code because compilers will continue to support deleted features (possibly requiring a compile option to suppress diagnostic messages.)
The goal here is to gently guide programmers away from a bad practice.
As a routinely Fortran programmer, I support obsoleting. In fact, I think implicit typing is VERY useful, not only because it saves me to not go back to the declaration space to declare just one locally-needed variable (e.g. for a loop), but also it can lead to a ‘standardized’ variable naming rule which helps debugging and readability. As a world-wide HPC and scientific computing language, I think Fortran should leave some space to teams to choose and build up a programming style, rather than eliminate a feature completely. Thanks for reading.
Totally agreed. When I see i, j, k, I immediately know they are integers, no confusion whatsoever. Why do I have to declare them? You need integer for indexing an array anyway, and some of them only appear in subroutines or small blocks of do-loops. Declaring and tracking types of a letter through a 10000 line code is sometimes annoying. It looks like implicit none is a trend. Well, my remedy is to declare integer::i,j,…n first thing in the code in case I forget them.
It will be better, I feel rather strongly, if the practitioners of Fortran and the standard bearers make attempts to distinguish between
a) implicit typing and
b) implicit mapping.
That is, to let `implicit typing` refer to the facility achieved by explicit IMPLICT statements in code such as `IMPLICIT INTEGER(I-N), DOUBLE PRECISION(A-H,O-Z)’ that are common in legacy FORTRAN codes based on FORTRAN 77 and its various extensions. Or in modern Fortran codes, the ubiquitous “implicit none” statement.
But for `implicit mapping`, see this first:
https://fortran-lang.discourse.group/t/eliminate-implicit-mapping/1612?u=fortranfan
and note that it refers to the specific mapping scheme in the Fortran standard, “If a mapping is not specified for a letter, the default for a program unit or an interface body is default integer if the letter is I, J, …, or N and default real otherwise” that has been rather detrimental to both the practitioners and to overall goodwill toward Fortran to remain as “lingua franca” in scientific and technical computing.
There is really no need for Fortran to even obsolesce, let alone delete `implicit typing` as distinguished above. If anything, under particular circumstances, it can even be accepted as a good coding practice (GCP) to make explicit use of IMPLICIT statements in the Fortran language. The important point though is that its use is really a CHOICE for the Fortran programmer.
`Implicit mapping` on the other hand must go. It FORCES a modern Fortran practitioner to introduce `implicit none` statement in each and every program unit AS WELL AS all the interface bodies. There is no choice in practice really, the `implicit none` statement has to be typed in AD INFINITUM. And note since MIL-STD-1753 starting 1980 i.e., over 40 years ago, almost every programming guide/requirements at major institutions such as NASA and US national labs, etc. and major companies and departments have sought to enforce the use of “IMPLICIT NONE” in one form or other. The situation now is there is hardly any code in Fortran known to the public domain that consciously seeks to employ the `implicit mapping` facility in the standard.
Thus the proposal now to delete `implicit mapping` only from the standard.
The readers should see ‘implicit mapping` as entirely separate from the implicit typing that can be achieved with explicit use of IMPLICIT statements which can go on forever with Fortran.
I invite everyone to read the following and provide your valuable feedback:
https://github.com/j3-fortran/fortran_proposals/issues/218#issue-957105668
Hi Steve, thank you for another article.
I use “implicit none” in my source code to avoid unintended problems with implicit variables. I feel that is an easy syntax to add to get the compiler benefit of checking the variables. I am in favor of the Fortran standard supporting older code to still compile.
To encourage avoiding implicit variables, perhaps the compiler could give a warning message if implicit variables are in use. The warning could be issued as a reminder to check the implicit variables, and the warning could suggest using “implicit none” to improve the code. To support both older code and encourage explicit variables, could this warning be skipped by a compiler option if desired? The compiler would encourage the default of explicit variables.
Greg, every compiler I know of has an option to complain about implicit variable use. The proposal here doesn’t affect IMPLICIT NONE. Obsoleting implicit typing would mean that compilers must have the ability to issue a diagnostic for it (typically when asked to check against the standard, though I know some compilers do such checks by default.) It could be disabled.
As I wrote above, the goal here is to get Fortran programmers to stop using implicit typing, not to make old code that uses it no longer compilable. This is no different from the other features already obsolete, such as fixed-form source.
In my opinion implicit typing is a useful feature especially for the scientific nature of Fortran language, e.g. it’s common in scientific problems to use local variables.
A declaration section full of local variables with imaginative names full of prefixes/suffixes would make a mess aesthetically and productively.
I think it’s a great and unique feature that we should not abandon or make obsolete. Also, I have trust in the power of reasoning at least in scientific fields, therefore I trust that newcomers in Fortran can make good use of the implicit typing and consider it a good practice depending on the problem they need to solve.
I’m not a fan of implicit typing. For the last 30+ years whenever I have a say I’m for requiring “implicit none” as part of project standards.
The effort to explicit type variables is never lost, IMHO. It is equivalent to commenting every executable action in your code. It makes you think about what you are doing and why.
It is the opposite of “quick and dirty” which as everyone who has had to maintain old code knows always becomes “slow and dirty” until it is either re-written or retired.
I was taught since the beginning use implicit none.
But I find it useful when autogenerating some code. For instance, Matlab will do symbolic match and output through the “fortran” function some fixed format code.
syms x y; fortran(taylor([exp(x),cos(y)],[x,y],’ExpansionPoint’,[1 1],’Order’,4))
produces a string
‘ T(1,1) = exp(1.0D0)+exp(1.0D0)*(x-1.0D0)+(exp(1.0D0)*(x-1.0D0)**2)
&/2.0D0+(exp(1.0D0)*(x-1.0D0)**3)/6.0D0
T(1,2) = cos(1.0D0)+(sin(1.0D0)*(y-1.0D0)**3)/6.0D0-sin(1.0D0)*(y-
&1.0D0)-(cos(1.0D0)*(y-1.0D0)**2)/2.0D0’
Always it uses T for the intermediate variables and results, so “implicit real(8) (T-T)” is handy when exporting this as part of a Fortran routine.
Love the blog.
If you know what you’re doing, then using the IMPLICIT statement is reasonable, but it should be reserved for unusual situations such as yours. I would suggest, though, that you do something like IMPLICIT REAL(8) (T-T),CHARACTER(A-S,U-Z) to make it more obvious if you forget to declare other variables.
There is a proposal (not yet accepted) for the next revision of the standard (after F2023) to deprecate default implicit typing (when IMPLICIT is not used.)