Eliminate implicit typing

[jacobwilliams]

In a similar spirit as #40.

I think most everybody agrees that implicit typing is a terrible "feature" that should never be used. Keeping it as the default behavior is a constant source of annoyance and errors. It's also just an embarrassment at this point. Why not get rid of it?

Removing it would require that people running obsolete codes put implicit double precision (a-h...) or whatever that is in all their codes, right? To me that's preferable to making everybody else suffer until the end of time.

[FortranFan]

@jacobwilliams , see also a couple of other recent threads: #79 and #83.

See also these 2 comments where I make similar points, even an entirely painful compromise (in my mind at least) to make the (NOT!) breaking change in free-form source since every free-form source out there already has (or intends to have) "IMPLICIT NONE" to signal implicit typing is not desired :
#83 (comment)
#83 (comment)

I entirely concur with your assertion, "It's also just an embarrassment at this point." As I write in one of the above comments, "Trying to get new coders to work on Fortran codes, particularly in industry, is a huge challenge. Few join with any background in Fortran, few schools teach Fortran. Then one loses them at 'hello' itself, meaning at the very beginning stage when one stresses to them the need to type 'implicit none' in every scope."

As I show with this link and with even another ISO IEC working group (WG23) document on vulnerabilities with Fortran, countless amount of time and effort is expended to ensure "implicit data declarations (are) banned, by inserting "IMPLICIT NONE' in all program units".

There is no reason any longer to leave such an important aspect to all the other coders and to anything else (e.g., processor options -fimplicit-none) but the goddamn standard itself.

Interestingly, one arm of ISO/IEC JTC 1/SC 22 in WG23 itself states the following which is unfortunately not paid heed to by the other in WG5:

7 Language specific vulnerabilities for Fortran

8 Implications for standardization 
  Future standardization efforts should consider:
  • Requiring that processors have the ability to detect and report the occurrence within a
    submitted program unit of integer overflows during program execution.
  • Requiring that processors have the ability to detect and report the occurrence within a
    submitted program unit of out-of-bounds subscripts and array-shape mismatches in
    assignment statements during program execution.
  • Requiring that processors have the ability to detect and report the occurrence within a
    submitted program unit of invalid pointer references during program execution.
  • Requiring that processors have the ability to detect and report the occurrence within a
    submitted program unit of an invalid use of character constants as format specifiers.
  • Requiring that processors have the ability to detect and report the occurrence within a
    submitted program unit of tests for equality between two objects of type real or complex.
  • Requiring that processors have the ability to detect and report the occurrence within a
    submitted program unit of pointer assignment of a pointer whose lifetime is known to be
    longer than the lifetime of the target or the target attribute of the target.
  • Requiring that processors have the ability to detect and report the occurrence within a
    submitted program unit of the reuse of a name within a nested scope.
  • Providing a means to specify explicitly a limited set of entities to be accessed by host
    association.
  • Identifying, deprecating, and replacing features whose use is problematic where there is
    a safer and clearer alternative in the modern revisions of the language or in current
    practice in other languages.

Considering the last bullet, nothing stands out as much as implicit typing and implied SAVE requiring immediate deletion from the Fortran standard.

[rweed]

@jacobwiliiams and @FortranFan, I think anyone who like me started with Fortran IV/Fortan 66 and then F77 (what I like to call Jurasic Fortran) and then moved to F90 and its decendents knows that implicit typing should have been removed from the language around the time of F90 (or before). Unfortunately, this is another one of those obsolete features that somehow take precedent over more modern and more useful coding constructs because of the "we can't break code" mantra. Every time I see this I immediately interpret it as "we can't break code by adding features or deleting obsolete ones that people are paying us money to help maintain". I'm becoming more convinced that the only way to save Fortran is to first declare that what is currently called Fortran has reached its "end of life" and is entering maintenance mode. Then maybe some enterprising young person will "fork" the language and produce a compiler that ONLY supports the things in the current standard that haven't been declared obsolete and strips out all the other cruft (DEC extensions etc.) vendors insist on adding and then give it a new name and market it is as a new language. I've alway wondered what price we are paying in the way of increased compiler bugs etc. because developers have to keep dragging the weight of all the obsolete stuff around just to satisfy a few hid bound organizations that are too cheap to make the effort to update their codes. I put the following question to the F18/LLVM/Flang developers and others. How much time and code are you wasteing trying to support features that have been declared obsolete by the standard and other things like DEC extensions. I guess what I'm saying is isn't it time we had a new vision of Fortran that doesn't include or support fixed source, implicit typing, all obsolete features and existing features we can all (mostly) agree were either a mistake to add to the language or are in their current form poorly implemented. I want a new standard that officially bans them and compilers that refuse to compile if it sees any of those features. Again, the only way I see that happening is to just fork what we can all agree are the best parts of "modern Fortran", come to a consensus on what new features we think would add value to that core capability and if necessary
write an new standard, call it a new name, and market it to the world as a new language.

As to @jacobwilliams proposal, I still see this as a procedural issue with the vendors more than a technical one. The path of least resistance is to make explicit typing the default and have compiler switches that people who insist on still doing implicit typing must turn on to get the old default. To me this is the logical approach since no mods would have to be made to old code and the only impact I can see is on build options

just my 2 cents

[certik]

@rweed Thanks for the feedback. I just created an issue for this in LFortran (a compiler that we are developing): https://gitlab.com/lfortran/lfortran/issues/148. I thought very hard about whether we should simply create a new language, and came to the conclusion that it's better not to: by sticking to Fortran's syntax and staying compatible, it means we can leverage the excellent Fortran compilers out there, that generate highly optimized code (historically better than LLVM, although the gap has been shrinking). If we create an incompatible language, then we are starting from scratch. And we can't use it with so many Fortran codes out there.

The other aspect is that if somehow Fortran compilers stop compiling our codes (and we have millions of lines) because Fortran becomes incompatible, it will only accelerate the exodus from Fortran in my opinion.

Note also that there have been such efforts to remove old stuff and only stick to modern Fortran, I believe https://en.wikipedia.org/wiki/F_%28programming_language%29 was one such attempt. I don't think it was ultimately successful.

I think there is a way to modernize the language, while staying compatible (for example with a compiler option). We just have to try.

[FortranFan]

@certik wrote:

@rweed Thanks for the feedback. I just created an issue for this in LFortran (a compiler that we are developing): https://gitlab.com/lfortran/lfortran/issues/148.

That's most commendable, thank you for pursuing such an approach with LFortran.

.. Note also that there have been such efforts to remove old stuff and only stick to modern Fortran, I believe https://en.wikipedia.org/wiki/F_%28programming_language%29 was one such attempt. I don't think it was ultimately successful.
..

The name matters a lot, if they had been strongly irredentist to call their effort Fortran also, the outcome could have been different!

[FortranFan]

@rweed wrote:

.. I guess what I'm saying is isn't it time we had a new vision of Fortran that doesn't include or support fixed source, implicit typing, all obsolete features and existing features we can all (mostly) agree were either a mistake to add to the language or are in their current form poorly implemented. I want a new standard that officially bans them and compilers that refuse to compile if it sees any of those features. ..

@rweed, I'm completely sympathetic to and understanding of your sentiments.

Sooner or later, the question "For whom Fortran?" will need to get addressed earnestly.

And I can only hope that will result in the realization Fortran needs to transcend and rise above the confines of ISO IEC standards body bureaucracy. That it's the latter who will have to follow the language where it freely needs to go. One can notice that clearly with C++ and the rapid pace and expansive scope and brave conviction of each ISO revision. Whereas many others on the IEEE Spectrum of most popular languages in the technical arena such as Python, Java, C#, R, MATLAB, Swift, Go, and even other HPC ones such as Julia, Haskell, etc. don't even bother with such standards bureaucracy but with no less success, that's for sure.

There is a lesson to be learned here: at some point, the 'bureaucracy' will need to adopt the US Marines ethos: lead, follow, or get out of the way.

The current snail's pace of incremental abominations of the likes of implicit none (type, external) is like adding insult to injury.

[certik]

By the way, is it possible to separate this kind of "meta" discussion to dedicated threads?

Yes, I encourage everyone to do so please. When you see a related but ultimately separate discussion, feel free to open a new issue and move it there. Sometimes it's hard to do, as we are discovering the "space" of arguments and we end up discussing these meta questions as we encounter them. But as we get better at this, we will eventually have dedicated issues with these meta questions so that we do not need to repeat the arguments.

[FortranFan]

Back to implicit typing: can anyone point to any code-base which explicitly (!) relies on this feature as part of their code design?

Over the last 6 years or so, I've reviewed lots and lots of code in legacy FORTRAN (66/IV/77 + non-standard extensions) spread over 75 programs and libraries and over a couple of million lines of instruction developed using dozens of person-years of effort spanning decades of contributions by many different engineers and scientists. All of these codes - without fail - either had

IMPLICIT INTEGER(I-N), DOUBLE PRECISION (A-H,O-Z)

or

IMPLICIT NONE

For codes like these with explicit IMPLICIT statements, a future revision of the standard that removes implicit typing as the default should cause no harm!

So it'll be really useful to know what other codes are out there which are of concern that Fortran cannot remove implicit typing as the default. And how relevant will these codes be in year 2035 or later when sufficient number of processors providing support for a revision with such a change start to appear? Note the earliest possible revision is Fortran 202Y.

I contend the risk of breaking old code is too low or nonexistent and that's not even taking into account the surefire possibility of vendors providing options to retain implicit typing as the default. It'll be an opportunity of some commercial potential at least for the vendors, something that should not be discounted completely.

So, "Why not get rid of it" as @jacobwilliams asked regarding implicit typing as the default in Fortran?

[rweed]

I've always assumed most (all) compilers supported something like gfortran's -fimplicit-none compiler option. If that were the case then making implicit none the default would be a procedural or policy decision and not a technical one. You just change the default polarity of that option. Unfortunately, a quick review of compiler documentation of the compiler's I use or have used in the pass shows that (as far as I can tell) only Cray and gfortran support an implicit-none option. I can't find any reference to an equivalent option for Intel, PGI, or IBM. They may exist but I didn't see any reference to one.

[milancurcic]

I can't find any reference to an equivalent option for Intel, PGI, or IBM. They may exist but I didn't see any reference to one.

It's -implicitnone for ifort if I recall correctly.

[rweed]

@milancurcic, I think that only turns on warnings about implicit typing. It doesn't enforce explicit typing by default. The only reference in the man pages to -implicitnone for Intel 19.0.5 is in relation to -warn options

[FortranFan]

@rweed wrote:

.. I think that only turns on warnings about implicit typing. It doesn't enforce explicit typing by default. The only reference in the man pages to -implicitnone for Intel 19.0.5 is in relation to -warn options

They don't make it easy, Intel Fortran customers have to write -warn declarations, errors (or /warn:declarations,errors on Windows):

C:\Temp>type p.for
      I = 42
      END

C:\Temp>ifort /c /warn:declarations,errors p.for
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 19.0.5.281 Build 20190815
Copyright (C) 1985-2019 Intel Corporation.  All rights reserved.

p.for(1): error #6717: This name has not been given an explicit type.   [I]
      I = 42
------^
compilation aborted for p.for (code 1)

C:\Temp>

[FortranFan]

@rweed wrote:

,, Unfortunately, a quick review of compiler documentation of the compiler's I use or have used in the pass shows that (as far as I can tell) only Cray and gfortran support an implicit-none option. I can't find any reference to an equivalent option for Intel, PGI, or IBM. They may exist but I didn't see any reference to one.

NAG Fortran documentation states:

-u
    Specify that IMPLICIT NONE is in effect by default, unless overridden by explicit IMPLICIT
    statements.

And the same with IBM XL Fortran

[FortranFan]

But doesn't the standard only have the concept of "Fortran processor" and formally ignore the existence of any specific devices/software (including compilers and options)? If compiler options are a valid approach (for the standard) ..

As stated, the desired goal of this thread "Eliminate implicit typing" has an overwhelming non-technical component i.e., beyond the boundaries of syntax and semantics of the language. The risk of breaking old code is among them. The long history of compilers and options come into play only as much to show the risk is rather low or non-existent to be used as a crutch to further kick this can down the road.

IMPLICIT NONE was among the most widely adopted non-standard extensions to FORTRAN 77 in processors starting in the 1980s. And there are countless coding guidelines and rulesets out there that required its use which clearly shows the practitioners of the language have overwhelmingly desired to move away from implicit typing. But that the very same processors will adopt options to support the miniscule minority (it it at all exists) who may want to continue employing implicit typing. That there is no reason to force the majority to suffer from the tyranny of such a minority.

[FortranFan]

@septcolor wrote:

.. For example...

AMOS (A Portable Package for Bessel Functions of a Complex Argument
and Nonnegative Order) ..

@septcolor , thank you very, very much for bringing attention to codes such as AMOS from NetLib collection.

However I do not think these legacy sources are good examples of code-bases where implicit typing is part and parcel of code design. These sources as-is have portability issues across current processors, see the comment on that GitHub repo. Then the good news is 33 out of 39 source files do not have implicit typing. Among the remaining 6 sources which do some problems with implicit declarations,

1. one source zbesy.f has a bug in that the variable R1M5 is clearly meant to be an object of double precision type but is instead implicitly typed as default real,

2. another source zunk1.f obviously has missed out on declaring a local variable M after having done so for all the other variables including the typical ones of I, J, etc.

Considering everything, I would not include codes likes these in any serious attempt toward assessing the risk of deleting implicit typing as the default in Fortran.

[sblionel]

In ifort, -warn declarations is all you need. This is equivalent to saying IMPLICIT NONE in every program unit. Don't get hung up on the use of "warn" - ifort is already inconsistent about which of these checks are warnings and which are errors (this goes back decades to the DEC implementations.)

[ThemosTsikas]

Briefly: It seems to me that the first step is to declare the following feature obsolescent (using J3/18-007r1, page 114, pg 130/646 of PDF, 8.7 line 9).

R863 implicit-stmt is IMPLICIT implicit-spec-list

Also delete:

First sentence of line 5
"In a scoping unit, an IMPLICIT statement specifies a type, and possibly type parameters, for all implicitly typed data entities whose names begin with one of the letters specified in the statement. "

Line 11
"R864 implicit-spec is declaration-type-spec ( letter-spec-list )"

Line 12
"R865 letter-spec is letter [ – letter ]"

Line 21
"C894 (R865) If the minus and second letter appear, the second letter shall follow the fi rst letter alphabetically."

Para 2
"A letter-spec consisting of two letters separated by a minus is equivalent to writing a list containing all of the letters in alphabetical order in the alphabetic sequence from the fi rst letter through the second letter. For example, A–C is equivalent to A, B, C. The same letter shall not appear as a single letter, or be included in a range of letters, more than once in all of the IMPLICIT statements in a scoping unit."

Second sentence of Para 3
"An IMPLICIT statement specifies the mapping for the letters in its letter-spec- list. "

Replace line 32, para 3
"mapping for all the letters. If a mapping is not specified for a letter, the default for a program unit or an interface"
with
"mapping for all the letters. The default mapping for a program unit or an interface"

Replace lines 37 -38, para 4
"type parameters) mapped from the first letter of its name, provided the mapping is not null. The mapping for the first letter of the data entity shall either have been established by a prior IMPLICIT statement or be the"
with
"type parameters) mapped from the first letter of its name, provided the mapping is not null. The mapping for the first letter of the data entity shall be the"

Delete last sentence of para 4
"An explicit type specification in a FUNCTION statement overrides an IMPLICIT statement for the result of that function."

NOTE 1 on page 115 needs to be rewriten

NOTE 2 on page 115 needs to be rewritten to show how to deal with the case where a variable is synonymous with a derived type, making it difficult to declare such a derived type. Perhaps the introduction of namespaces (#1) will make this much easier.

A NOTE needs to be added to show how to use other facilities when eliminating this form of the IMPLICIT statement.

Change example ("program fragment") in para 5, C.9.2.2, page 556, pg 572
"There is an increased potential for undetected errors in a scoping unit that uses both implicit typing and the USE statement. .... Logic errors resulting from this kind of situation can be extremely difficult to locate. Thus, the use of these features together is discouraged."

End of edits.

The next step would be to declare implicit typing rules obsolescent. Eventually, both will be deleted.

[FortranFan]

@ThemosTsikas wrote:

..
The next step would be to declare implicit typing rules obsolescent. Eventually, both will be deleted.

I agree with you in principle.

In practice, I'll be thrilled if the order is reversed in order to achieve a "compromise"!

Meaning, a relatively minor edit is made to the standard which is to effectively make IMPLICIT NONE the default. Now, I have not pondered over fully in terms of accuracy and the implications but my proposal is the paragraph corresponding to mapping of letters with types in the current standard i.e., 18-007r1 document toward Fortran 2018, Section 8.7 IMPLICIT statement, paragraph 3 be edited as follows:

[114:29-34]
Change

29 3 In each scoping unit, there is a mapping, which may be null, between each of the letters A, B, ..., Z and a
30   type (and type parameters). An IMPLICIT statement specifies the mapping for the letters in its letter-spec-
31   list. IMPLICIT NONE with an implicit-none-spec of TYPE or with no implicit-none-spec-list specifies the null
32   mapping for all the letters. If a mapping is not specified for a letter, the default for a program unit or an interface
33   body is default integer if the letter is I, J, ..., or N and default real otherwise, and the default for a BLOCK
34   construct, internal subprogram, or module subprogram is the mapping in the host scoping unit.

to

29 3 In each scoping unit, there is a mapping, which may be null, between each of the letters A, B, ..., Z and a
30   type (and type parameters). An IMPLICIT statement specifies the mapping for the letters in its letter-spec-
31   list. IMPLICIT NONE with an implicit-none-spec of TYPE or with no implicit-none-spec-list specifies the null
32   mapping for all the letters. **If a mapping is not specified for a letter in a scoping unit, the default is null**.
32   The default for a BLOCK construct, internal subprogram, or module subprogram is the mapping in the host scoping unit.

Such a small change - only one sentence in the standard is modified - will make a world of difference in the domains I work where the full intent of powers-that-be and also the coders is to have no default mapping of letters with types (e.g., no default mapping of n with integer, etc.) but they have to take great care to add IMPLICIT NONE to each scope or resort to compiler options, both of which are frowned upon by an overwhelming majority of the teams I have worked with.

And I'm personally convinced such a small change will have no adverse effect in other domains also because the situation everywhere is the same based on what I've researched: the intent everywhere is to have no default mapping of letters with types. Every code one can see on GitHub or SourceForge, etc. either includes or intends to have IMPLICIT NONE in all their scopes. So this small change of a proposal in this comment is only enabling what is overwhelmingly the practice.

[certik]

@ThemosTsikas thanks for your comment! And thank you for participating here. If you have any other comments or suggestions to other proposals or have some proposals of your own, please definitely comment or open new issues here.

[ThemosTsikas]

I think that the order I suggest has the merit that it first removes (or rather, marks as obsolescent) a bit of syntax before making changes in the semantics, and syntax is easier to check than semantics.

[ThemosTsikas]

In #90 (comment), I wrote what would be needed to delete the IMPLICIT implicit-spec-list feature. What is needed is similar text for the marking of the feature as Obsolescent.

[FortranFan]

To those interested in this issue, here's a comment to take note at comp.lang.fortran thread where "Lynn McGuire" posted:

The number one dysfunctional item in Fortran is variable typing and
declaration. At the 1977 specs, much less the 1990 specs, all Fortran
variables should be explicitly declared and typed. The implicit rule is
ok for small programs. Not at all for anything more than say, a
thousand lines of code.

[eprovst]

I've been thinking a bit more on this issue lately, especially having used Fortran some more (after seemingly having partially opened Pandora's box with this thread).

First four assumptions I'm making (which to my knowledge are true, but please correct me if I'm wrong):

1. We really want to get rid of implicit by default, but implicit semantics themselves don't have to go (in the short term at least).
2. Having code not compile—but not break—is a lesser evil than implicit by default, if that code can automatically be fixed.
3. If implicit none changes the semantics of the code, this always results in the code failing to compile.
4. Program units are easily detected.

If these assumptions are true, getting rid of implicit typing as a default is actually pretty straightforward:

Make implicit none the default in the next standard and include a tool that detects the outer most program units, sees if there is any implicit statement and if not adds

IMPLICIT INTEGER (I-N), REAL (A-H, O-Z)

Optionally this tool could even verify if this change is needed, but it doesn't have to.

Additionally we could deprecate the implicit statement all together and leave it up to vendors if they support old code or not.

[certik]

Thanks @elecprog for writing down the assumptions that you used. Under your assumptions I think your proposal could work.

The issue that we have is that we can't get a community agreement on the assumptions. I have seen opposition to the assumption 2., and consequently also 1. I personally agree with 2. (i.e., implicit by default being more evil), but some others disagreed (older code not compiling being more evil: Fortran historically tries very hard to compile older code, so I understand this position).

[jacobwilliams]

FYI:

• How to solve the same numerical Problem in 7 different Programming Languages
• subsequent discussion on fortran-lang Discourse

[jacobwilliams]

I think we spook people when we talk about tools and code changes. The proposal should be this and only this:

• The feature in Fortran that automatically sets the type of undeclared I-N variables to integer and other variables to real is deleted.
• No other language changes related to this are done. implicit none is still valid, implicit double precision (a-h,o-z), etc. are all still valid. implicit none becomes redundant, but that's OK (just like recursive was made redundant in a recent standard, but is still valid)
• Code that has undeclared variables (or variables not covered by an implicit statement) is now a syntax error.
• BUT, the compiler vendors are expected to provide a command line argument (e.g., -f-allow-implicit-typing that reenables it, so undeclared variables will work the same way they always have for those users not able or willing to modify their code.

That's it. Very simple and doesn't change the behavior of any code. All the maintainers of a legacy code has to do is add a single command-line argument to their build system. They don't have to change a single line of code if they don't want to.

But, the important part is that new codes no longer have to type "implicit none" everywhere. We get that automatically. Implicit typing no longer has to be explained on page 1 of the Fortran Getting Started manual, it's moved into the appendix, and new users who want to write modern code never have to worry about it or even know it ever existed. An entire class of bugs that have plagued Fortran programmers for decades will disappear forever. We can finally move on.

[klausler]

J3 will sometimes change the semantics of newer conforming code, but it is very unlikely that they would change the semantics of a large proportion of older code so as to require a new compiler option to make existing (c)makefiles and source code continue to work.

I suggest that we define a new distinct Modern Fortran source file name suffix that would imply free source form and a few modest incompatible semantic changes: default IMPLICIT NONE(TYPE,EXTERNAL) and corrected DO CONCURRENT semantic guarantees are obvious possibilities. (I have a list, but the specific details don't matter as much as the general idea.) Get a few compilers to recognize the new suffix -- I think that it would not be a hard sell, at least for me -- and you'll have what you want without affecting any older codes.

(Addendum: This could of course also be done with a compiler directive !dir$ modern but that kind of defeats the purpose of making things less mysterious for newcomers. And my list includes: enable cpp-like preprocessing, disable deprecated features, disallow non-module subprograms, and give up on things like LEN parameters to PDTs that are still not widely avaiable.)

[milancurcic]

@jacobwilliams here are my suggestions:

1. Remove the last bullet (expect compiler arguments), it's a non-starter for a proposal to J3.
2. The first 3 bullets are redundant statements. Distill into the simplest and clearest message possible. Perhaps this is something along the lines of "Implicit typing must be enabled with the implicit statement", or similar. I'm not proficient enough yet with standardese to express it more appropriately.
3. Research what edits to the standard would need to be made to implement this; this is not required at this stage (idea pitch), but it would be helpful to demonstrate that this would be indeed a small change to the standard from an editorial point of view.
4. Write the proposal; research past successful proposals to get an idea for the style, structure, and contents. Include a thorough list of concrete downsides and upsides to this change. I suggest not writing in absolutes like "nobody's code will break" or "everybody wants this" if you want it taken seriously.
5. Submit a proposal as a PR in this repo. This will serve as the first filter before it's uploaded to J3. The sooner the better.
6. Find a J3 member to champion your proposal.
7. Join J3.

I think the proposal may have a slightly better chance if it proposes for marking default implicit typing as obsolescent rather than deleted. Traditionally features have been sunset gradually (obsolescent first, delete second), but there have been discussions about changing this process and deleting features on a shorter fuse.

[FortranFan]

@milancurcic wrote May 31, 2022 11:11 AM EDT:

3. Research what edits to the standard would need to be made to implement this; this is not required at this stage (idea pitch), but it would be helpful to demonstrate that this would be indeed a small change to the standard from an editorial point of view.

I have done the "research" and as I pointed in issue #218 my observation is only one sentence needs to be modified in the standard (18-007r1 document as proxy) which is in section 8.7 IMPLICIT STATEMENT page 114, paragraph 3, lines 32-34.

In order to achieve the desired change, the relevant sentence can be changed to something along the lines of:

"If a mapping is not specified for a letter, the default for a program unit or an interface body shall be NULL, and the default for a BLOCK construct, internal subprogram, or module subprogram is the mapping in the host scoping unit"

Readers can peruse 18-007r1 document or issue #218 for what the standard states currently.

[FortranFan]

my observation is only sentence needs to be modified in the standard

@jacobwilliams , I hope you will be leading this based on your prior comment and your insistence on closing issue #218 even though so many things are on the wrong track here in this thread, starting with your poorly worded title itself.

It should be obvious to any reader the root matter is mostly non-technical, it is a vision thingy really for Fortran to head in the direction of explicit declarations. All indications are most on the committee do not align with any such vision, or any vision period. Most voting members would rather live with the status quo for eternity. There is a monumental hurdle to be overcome here.

So I hope you will follow all the right steps from this point forward - which are all administrative "process" and the "right manners" based as laid out by @milancurcic - in order to try to bring about the right influence on the committee(s).

Perhaps you want to watch this video first and do as indicated to avoid the "no soup for you" fate.

[certik]

Everybody, let's be nice to each other. We are all in the same boat. As I mentioned at the Discourse thread, LFortran already "eliminated implicit typing" by default, and I encourage other compilers to follow suit.

Regarding the standard, @jacobwilliams, do you want to take a lead on this?

[klausler]

Has there been a WG5 or J3 proposal paper in the past to make implicit none(type) the default? The archive isn't very searchable and it only goes back to 2006, so maybe I've missed a paper on this topic.

[gklimowicz]

Since implicit none was introduced in Fortran 1990, I suspect that any papers that reference making it a default only exist in hard-copy form. Here's what I can see in my offline archive of all the digital papers I have laid my hands on. There are 442 references to the phrase, but most are in program examples.

Paper 03-153.txt, around line 78:

j. WG5 was undecided whether the default implicit rules in a
submodule should be those of its parent or implicit none and
encourages J3 to consider this further.

A vote on submodules and implicit none was recorded in 03-210.txt, near line 206:

The default implicit rules for a submodule are those of 
its Parent, Implicit none, usual Default rules
or Undecided?                                           P I D U
                                                        4 5 0 3

We should probably ask Peter's question in comp.lang.fortran.

[certik]

Thanks @gklimowicz ! So that is interesting: nobody voted for the "usual Default rules". Most people voted for "Implicit none" to be the default.

Also: there where only 12 people voting. There are already 10 participants who commented in this issue, and 23 (!) who upvoted the issue. So to me it means that there is clear interest in revisiting this.

[klausler]

Inventing the implicit typing behavior for a new feature like submodules wouldn't affect any existing code, of course. But it's odd, given this vote, that submodules (and more important, separate module procedure interfaces) ended up with the same old rules by the time they were published in F'2008.

I look forward to seeing what happens when a proposal that would require source changes to legacy codes is put forward. Is somebody going to write this up as an official paper?

[FortranFan]

Is somebody going to write this up as an official paper?

Based on the thumbs up voting trail upthread, I expect @jacobwilliams and the nice folks will write up the "official" paper.

[FortranFan]

any papers that reference making it a default

I hope any such papers and prior votes are only of historic interest.

Any proposals, if present at all to make implicit none the default, clearly got voted down ultimately and that's why the standard is the way it is now with implicit mapping rules pervasive across all the program units.

I will hope past performance of the committee(s) is not indicative of future results.

[klausler]

any papers that reference making it a default

I hope any such papers and prior votes are only of historic interest.

Any proposals, if present at all to make implicit none the default, clearly got voted down ultimately and that's why the standard is the way it is now with implicit mapping rules pervasive across all the program units.

I will hope past performance of the committee(s) is not indicative of future results.

Will you champion this paper at J3, if it is written?

[FortranFan]

any papers that reference making it a default

I hope any such papers and prior votes are only of historic interest.
Any proposals, if present at all to make implicit none the default, clearly got voted down ultimately and that's why the standard is the way it is now with implicit mapping rules pervasive across all the program units.
I will hope past performance of the committee(s) is not indicative of future results.

Will you champion this paper at J3, if it is written?

@klausler , sincere apologies if the question was not addressed to me - I have presumed as such because my comments got quoted.

My response will be as follows: assuming the paper is a single topic one and it focuses on doing away with the implicit mapping along the lines of a possible one-sentence change (see above), meaning a minimally complicated brief paper honed in to make implicit none the default, I will be more than eager to lend it my fullest support in any way possible including all J3 discussions where I might be able to contribute and particularly with any straw votes. And if I were a full voting member, I would have been more than eager to champion it also, alas I am not. My gut feel though is getting a commercial vendor or two who are full voting members to champion a paper can prove to be a far positive influence.

[klausler]

any papers that reference making it a default

I hope any such papers and prior votes are only of historic interest.
Any proposals, if present at all to make implicit none the default, clearly got voted down ultimately and that's why the standard is the way it is now with implicit mapping rules pervasive across all the program units.
I will hope past performance of the committee(s) is not indicative of future results.

Will you champion this paper at J3, if it is written?

@klausler , sincere apologies if the question was not addressed to me - I have presumed as such because my comments got quoted.

My response will be as follows: assuming the paper is a single topic one and it focuses on doing away with the implicit mapping along the lines of a possible one-sentence change (see above), I will be more than eager to lend it my fullest support in any J3 discussion where I can contribute and particularly with any straw votes. And if I were a full voting member, I would have more than eager to champion it also, alas I am not. My gut feel though is getting a commercial vendor or two who are full voting members to champion a paper can prove to be a far positive influence.

You should write the paper, then, to ensure that it matches your concept of the change.

[klausler]

I don't see a paper at https://j3-fortran.org/doc/meeting/227 yet. This may be your only chance in the next 3-5 years to get this topic on WG5's agenda.

[sblionel]

A paper is not required or even desirable at this time. I have asked each member to submit a list of five features/changes they want to see in 202Y, and we will start discussing these in Boulder. It is not the “only chance”, but I expect that the list will be refined by the 2023 meeting. This is similar to the process we followed for 202X and there were many more suggestions than we could accommodate.

FWIW, deprecating implicit typing is on my list.

[difference-scheme]

I suggest that we define a new distinct Modern Fortran source file name suffix that would imply free source form and a few modest incompatible semantic changes: default IMPLICIT NONE(TYPE,EXTERNAL) and corrected DO CONCURRENT semantic guarantees are obvious possibilities. (I have a list, but the specific details don't matter as much as the general idea.) Get a few compilers to recognize the new suffix -- I think that it would not be a hard sell, at least for me -- and you'll have what you want without affecting any older codes.

@klausler I have long held the view that what you suggested above is the way to solve this problem. Hardly any of Fortran's present-day defaults is conducive to modern-day programming, so this would help fix all of these defaults in one fell swoop. My top three suggestions for defaults would be the following:

1. "implicit none" (in all scoping units)
2. "private" (in all module scopes - yes, everything in a module should be private by default)
3. "import; implicit none" within the scopes of (abstract) interfaces (interfaces should have access to all the declarations of their hosting module - this is the only sensible default, as in any other reasonable language)

[klausler]

Since F'2023 is inbound with at least one breaking change, multiple suffixes might be best. foo.f23 would be free-form source with F'2023's breaking changes expected by default, while foo.f90 and foo.f would continue to work without being affected by the breaking changes of F'2023 (and 202Y) unless a compiler flag or directive appeared to enable them.