Putting a feature in the obsolescent section “forever” would be an acceptable compromise. I don’t know what the standard says about how the compilers should handle the obsolescent features, but IMHO the compilers should by default issue warnings.
IIRC, in f90/f95 assigning any array (allocatable or not) with an array of a different size was illegal, and when it could not be caugth by the compiler the runtime behavior was processor-dependent.
F2003 now authorizes such an assignement if the LHS is allocatable. But the behavior of legal code has not changed, it’s just that what was illegal and with an undefined behavior is now legal and defined.
Yes, that is extremely important to be able to delete deleterious features and move forward.
By the way, in terms of Fortran “standardese”, marking something as obsolescent is more like a label from the language semantics and syntax point of view - all future feature developments need to work consistently with those marked as obsolescent.
So take alternate return for example: it will remain obsolescent into the foreseeable future, however any new facilities, say with subprograms generally or with template procedures in the future, will also need to take alternate returns into consideration - often it can be extra work to simply mark out a lack of support for the old undesired feature or to figure out how to get the obsolescent feature to behave benignly with the new one. Fixed-form source is a more relatable example though, which can affect the choices with any new syntax.
First of all, there is nothing, absolutely nothing in a revision to a language standard that can “kill” the language.
On the other hand, the other, better proposal to remove implicit mapping will only help the language, it does not affect in any way the explicit use of IMPLICIT statements - thus the option for implicit typing remains for those who want to indulge in it, it is only that the default becomes implicit none per a future revision of the standard.
Kargl is right that the program was bad f95 but constraints were not the only things compilers had to complain about if violated because the f95 standard 1.5(3) also mentions numbered syntax rules such as 2.4.5, 7.5.1.2 and 7.5.1.4 in the present case.
You guys who are advocating changes to implicit typing need to be clear about what you are proposing. When you say “eliminate implicit mapping”, to most of us that means eliminating implicit statements of all kinds, and thereby making fortran like C and other languages that require explicit type declarations of all variables. Instead, what you are saying now is that you want the default to change from one type of implicit mapping to implicit none. That is also a backward incompatible change with existing source code, but it is a different kind.
In any case, I still think you should come up with a proposal that is backward compatible.
There have been several posts at this forum, J3-GitHub, other sites, etc. over the years where I have consistently mentioned the need to differentiate between “eliminate implicit typing” and the better one which is to remove implicit mapping. Great attempts have been made to explain the latter i.e., to remove implicit mapping only makes a few, low-cost changes to the standard - primarily it is a change to a single sentence as shown in the link in the first sentence - which makes implicit none the default and standardizes the intent of all practitioners today which is to explicitly declare all objects in programs.
The maintainers of old codes having an option to insert
implicit integer(i-n), real(a-h, o-z)
is more than good enough in terms of backward compatibility. The vendors obliging them with never making the newer standards the default semantics is an additional crutch that is more than good enough.
There is no need to place any further demands on those submitting proposals here.
There are some deleterious features where the notion of backward compatibility is a needless noose being placed around the language.
Fortran strives for backward compatibility but, thankfully, has never been a prisoner to it. The list of deleted features I expounded upon upthread are prime examples.
There is no need for anyone to get carried away with the backward compatibility bogeyman in the context of implicit mapping.
I agree with @FortranFan, what we are proposing is a symbolic change. But a very important one that will help us move forward.
Literally just two weeks ago we implemented implicit typing as an option into LFortran (not because it is in the standard, but because old codes need it) and we are not removing it (whether or not it gets removed from the standard). In the same way, other compiles will also not remove it.
Does Fortran aspires to be a big tent of many different users?
Or is it simply meant to be used by a select few in big $$ taxpayer-funded institutions who keep running “old codes” and a few hobbyist or single/small team coders who will easily cater and crater to “power” and say “I don’t mind implicit none” and daftly go about typing it everywhere and not care about others who don’t want to be that way any longer, at least in year 2032, noting the practitioners like mindless minions have been inserting implicit none in all their units since the late 1970s and wondering when they can stop with this nonsense.
With the teams I am working with where there is the potential of large, large teams developing many big, big simulation applications and also tools around their workflows involving literally trillions of dollars of infrastructure investment toward the transformation of energy industry away from fossil fuels. The coders and managers simply don’t want to see, hear, or write implicit none anymore, ok? With such massive investments at stake, a basic consideration is type safety in the new code being developed. And there is no single way besides the standard to go about this in Fortran: it’s one thing with Intel Fortran, another with AMD, a third with GCC, a fourth with NAG Fortran, etc… More importantly though, the coders want to arrive at ISO-certified workflows with ISO standard code at play i.e., Fortran standard code where they will not be required to insert implicit none all over the place. No one has the time to give a damn about the 1950s and IBM and implicit typing and FORTRAN history, ok?
Why cannot the needs of these new users be met by the Fortran standard? Why in the hell are some people always bringing up so much resistance at a possible change more than a decade from now that does not affect them any, it has no affect on existing codes, and it simply standardizes what everyone is doing now anyway? This only matters because the needs of practitioners is effectively dictated by a silly plebiscite-like scheme, a lot of “up” votes, or at least few to “no” down votes. The resistance and incessant opposing comments lead to lack of support because the compiler vendors only see current paying customers, they entirely fail to the potential of new customers and thus, they resist change.
Is it extreme bias and discrimination as to for whom Fortran is supposed to be and for what purposes? Is it being a soupn$@!, the ultimate parody of extreme bias and discrimination in current times where it shall depend on who is asking for something and how, otherwise it is “no soup for you” angry retort in the world of Fortran?
Why are some people so attached to variable names starting with i thru’ n to be integers by default when they can achieve the same by inserting just one line themselves rather than forcing everyone else who doesn’t want that to insert a line everywhere to disable that?
When allocatable arrays are are involved, it is mostly impossible for a compiler to see that that sizes are not the same. However if in the code above you replace the allocatable array by a static array, gfortran returns an errors on the assignement.
This (the words in bold) is not entirely true, and you even acknowledge that when you say that people would just have to insert the legacy mapping rule in the old codes.
Besides, constantly charging people who disagree with you of being dumb (because this is what you really mean at the end) doesn’t look the best way to make them change their mind…
I think there is some confusion what exactly is being suggested: whether you have to insert implicit mapping in old codes or not. I personally suggest old codes must always run unmodified (perhaps with some compiler options).
That f2003 change, whether you like it or not, was backwards compatible. It did not change the meaning of previously standard-conforming code. That is what those who advocate changes to the implicit declaration default need to do. They need to find a way to change the standard to do what they want without making existing standard conforming code illegal.
It’s great if the “requirement” were for the conforming processor to offer some options (or even none like Intel) to process conforming “old codes”. The teams I work with would simply the future standard to have implicit none as the default everywhere even if that takes the equivalent of -standard-semantics with Intel processor to achieve it
But that’s not the problem here.
First consider the standard: when it comes to source, it does not recognize anything else other than its form, whether it’s fixed-form or free-form. Now the general premise and a string position by the vendors is there cannot any distinction in semantics between the two source forms. So outside of the suggested change with the one-line sentence change re: getting rid of I-N mapping and related phrase, anything else in the standard will be either unworkable or put in a lot of effort, say build an edifice of something else like files and extensions or some such.
Now let’s get back to the issue here with implicit typing: the problem is with the demand for backward compatibility, the tacit requirement being the future standard revisions forever should consider hypothetical “old codes” as conforming even as an overwhelming fraction of actual “old codes” are all broken with respect to the current standard in more ways than one.
Given then how all the challenges and constraints at play here, there is no backwardly compatible solution. But those who cling on to the standard support for implicit mapping already know this, so for them it is an easy way to “kill” the proposal to eliminate implicit mapping and achieve status quo. But that’s not good for the language. For possible millions lines of unseen “old codes” including immutable ones like in old textbooks, the language is missing out on so much new code and so many new apps and domains which could be in Fortran. It’s such a failure of vision and imagination.
I would say that this is the problem even before any details are discussed about implicit typing. The actual problem is with any demand to break backward compatibility, not with the demand to keep it. Of course, that tradeoff is sometimes worth it, but the proponents for the change must make that case and convince everyone. In the default implicit none case (which is not the same as eliminating implicit typing), the gains are minimal while the risks are great. In practical terms, the effort that is (and will be in the future) required to add the “implicit none” declaration, especially in the context that that must also be associated with explicitly typing every variable, are negligible.
With a few possible exceptional corner cases, any program that works correctly with “implicit none” line will also work correctly if that line is removed. That is, the line itself is unnecessary as far as the semantics and the interpretation of the code by the compiler. Yet there are those who want to invalidate 60+ years of legacy codes and textbooks and code repositories in order to enforce something that is, by its nature, redundant in the final code.
If it is redundant in the final code, then why use it? Implicit none is useful to the programmer during the development process. It helps detect misspellings, including in fixed-source form when the line exceeds column 72. That is it! It helps the development process. I admit that I use implicit none typing almost universally, but others don’t. Why should I impose my development preferences on others, particularly when it invalidates 60+ years of legacy codes? I choose not to do that, so unless a backward-compatible change is proposed on this matter, I would not support it.
@certik, given your long-standing and highly popular proposal toward NAMESPACEs, say you take a look again at further developing the suggestion in the other thread at the J3 Fortran proposal site:
Now please see this comment I just added there. What would be your thoughts? With your vast experience, especially with LFortran, is that something worth a consideration?
So the readers will note the thought is this:
make implicit none the default in NAMESPACEs and develop proper scoping rules for all the program units that are enclosed in a NAMESPACE to have by default the same implicit mapping scheme as the enclosing NAMESPACE.
So refer to the original post to review the proposal on “proper” NAMESPACEs:
say a namespace n encloses module m. Then the default implicit mapping in module m shall be that corresponding to implicit none.
if there is interest and value in this, then the NAMESPACEs shall support IMPLICIT statements, say implicit integer(i-n), real(a-h, o-z) in which case all the modules in that NAMESPACE shall have the same implicit mapping as what is currently in the standard.
To reiterate,
namespace n
! `implicit none` is the default
module m
! "inherits" the default `implicit none` setting from enclosing scope which is the `NAMESPACE`
..
end module m
..
end namespace
Please note also another thought is to support semantics and syntax somewhat like submodules to permit “free-standing” modules:
namespace(n) module m
..
end module
Depending on the feedback of compiler developers, the NAMESPACE may need to list the enclosed modules:
namespace n
module m
module o
...
end namespace
With a “proper” NAMESPACE facility, a bit of a feedback I have is the codes of interest to a couple of possible large teams who are considering big, new, production codes for simulations with components also possibly in modern Fortran will be very open to enclosing all the Fortran modules in namespaces and thus having implicit none the default will allow all such modules to “inherit” without having to explicitly override the implicit mapping rules in the standard for other program units.
Then if the program units that are not in enclosed namespaces as shown above, which is every unit now, then they get considered by the standard as no-namespace program units a la external procedures, meaning these units follow the current implicit mapping scheme. No issues with backward compatibility therefore.
This way, only the new codes which employ namespaces achieve the implicit none by default.
I think this satisfies the backwards compatibility condition, and I could imagine using this routinely in my codes.
I only would point out that in the single subroutine or single module case, this proposal would replace a single IMPLICIT NONE statement with the pair of statements NAMESPACE and END NAMESPACE. For multiple routines or modules, the two-line effort is amortized, so the programmer comes out ahead.
Another general problem with this is that I prefer to break up fortran codes into separate files as much as possible. With f77, that means usually one subroutine per file. The main reason for this is that it makes program builds faster during the development and debug stages. With modules, you can’t do this, each module is typically some number of closely related subroutines grouped together, and then there is one module per file. With the NAMESPACE approach, this would be even worse. A programmer might be inclined to group several modules together into a single file, with one NAMESPACE block per file.
I don’t like it. There’s no real logical connection between the concept of a namespace and the default implicit options. This would just make Fortran rules feel more convoluted, especially for the new practicioner, and probably result in an even more error prone situation. Why would you expect a namespace and a module have different type system settings? Would you just send the message that namespaces are modern and modules not? That would be an error in my opinion and give the feel of a “patched” language even more than having to put implicit none everywhere. At least the current (annoying) situation is clear cut and difficult to forget about (if something weird ever happens with your declarations it’s just “oh the implicit none” and that’s it, simple).