This is precisely what I meant above which others described as “horrible”. Different strokes for different folks.
Making it easy today sometimes stores up pain for tomorrow. The language offers ONLY and ASSOCIATE so that later contributors will not be mystified by code.
I agree, my approach is also to be very restrictive by default, and one has to relax the restriction with a compiler option. So probably a good solution is to just give an error (or at least a warning) when symbols conflict, and guide the user to use only to disambiguate.
This feature also obscures, or at least isolates, the implementation details of a module from the modules and subroutines that USE that module. Suppose for example that a sequence of modules is written with no conflicts. Then at later times, those modules are modified by adding variables and subprograms so that conflicts do occur. With the fortran conventions, the rest of the modules in that sequence do not need to know about those details since they did not reference those conflicts in the first place. The sequence of modules all continue to compile correctly, the loader continues to make the executables, and the executables continue to run because those conflicting entities are not referenced. If the other convention had been chosen, then when those conflicts were introduced the programmers of the other modules in the sequence would have needed to modify their codes, either by renaming the conflicting entities, or with the only clause, or some mixture. So you can see why fortran made the choice that it did, it allows the development and maintenance of separate modules to be treated more independently.
I’ve asked the OP’s question almost verbatim to ChatGPT (Plus), and it seems to support the interpretation by gfortran, flang, and Lfortran (even when use, only: foo is used). It suggests that “Annex A” was useful for interpretation, so the latter section might contain some more info… (But please keep in mind that answers from LLMs may be wrong, although it seems to have used the Standards PDF in the OP’s post for analyses.)
(Below is some of the replies. I’ve asked also about Annex A, but the answer was not very clear about the location of the original texts.)
The standard-conforming reading is:
your program is allowed, because foo is not actually used in the program body. So in this case, the behavior of gfortran, flang, and LFortran matches the wording of the Fortran 2023 draft more closely than Intel’s rejection does.
The key point is the sentence you quoted from 14.2.2 p8:
an accessed entity may be associated with two or more ultimate entities unless its identifier is not used.
That “used” means used as a name in the scoping unit for semantic purposes—for example in a reference like
call foo()
x = foo(...)
print *, foo
It does not mean “mentioned syntactically inside a USE, ONLY: list”. The ONLY list controls which names become accessible; it is not itself a reference to the entity in the sense relevant to the ambiguity rule. This reading is reinforced by the informative Annex text, which explicitly says that if two modules contain entities with the same name, and none of those entities are to be used, they can simply be ignored.
So your example
program main
use A, only: foo
use B, only: foo
implicit none
end program main
is valid under that reading, because:
foofromAandfoofromBare both accessible,- but the identifier
foois never actually referenced inmain, - therefore the ambiguity never becomes semantically relevant.
By contrast, this version is clearly ambiguous and should be rejected:
program main
use A
use B
implicit none
call foo()
end program main
and current compilers generally do reject that.
So to your direct question:
No, use A, only: foo should not itself count as “using the identifier foo” in the sense of 14.2.2 p8. The ONLYclause makes foo accessible; it does not by itself constitute a semantic reference that triggers the ambiguity prohibition.
EDIT: Here is the link for the full output of ChatGPT (please note, however, that it is very long because I made several subsequent questions like the wording in the Standards and Annex A.)
This is an interesting set of replies from AI.
I would have stated this differently. foo was already accessible (although with name conflict) from just the use statement; the only clause rather makes everything else within those modules inaccessible.
Something is wrong with this quote, should it rather say “an accessed entity may not be associated with two or more ultimate entities unless its identifier is not used.” ?
In Fortran 2023, I was able to find this exact quote:
“An accessed entity shall not be associated with two or more ultimate entities unless its identifier is not used, or the ultimate entities are generic interfaces.”
So my understanding of this is that if both modules A and B have foo as public entity and you use both modules to bring both foo into scope, then:
- Either
foois a generic interface, so bothAandBcontribute some specific implementation of it and you can “use”fooin your code just fine - Or you do not actually “use”
fooin your code and that is also allowed
Every other case is not allowed.
I’ve just checked the reply of ChatGPT again (which I posted above by copy-pasting the output), and the quote in the reply was indeed “an accessed entity may be associated with…”. Because my prompt just copied the question of the OP as-is (so quoting “An accessed entity shall not be associated with…” from 14.2.2.p8), I believe ChatGPT has erroneously changed the quote (i.e., “shall not be” to “may be”)! When I read them yesterday, I focused on reading the non-quote parts of the reply (particularly with bold fonts), so I did not notice that… So thank you very much for pointing it out!
(BTW, this kind of erroneous behavior of ChatGPT sometimes occurs also in my personal use, although the frequency has been decreasing recently. That is, the replies are mostly useful in extracting key insights from existing literatures, while sometimes confidently making an erroneous statement in some parts… When I already knew the answer, I usually point out the mistake to ChatGPT, and then it usually “thanks” to me for pointing it out
So I still feel that cross-checking is essential when using LLMs for any serious / practically important use, though it is very handy for “daily” use (like asking options of some commands etc).
BTW, the replies of the above post also contained some speculations why Intel compilers behave differently, and also about the usage of the word “reference” in the Standards. But the replies were very long, so I have not been able to read them carefully…If they contain some useful info, I will post them later.
You have to use AI in the mode where it looks up things online and in documents. Don’t use a “quick” mode where it just answers without looking anything up.
I have a project setup in Grok where it has access to the Fortran 2023 standard as a pdf. Here is my session from a few days ago:
It turns out the above quote was there cited as well, correctly.
Actually, I have started using the non-free account of ChatGPT only recently, and it searched the net + Standard PDF for about 20 seconds until it started to show the first reply posted above. I think the useful resources are very limited for the interpretation of the Standards, plus the PDF is very complicated, so I guess the accuracy can be worse for extracting information (e.g., as compared to python-related questions).
So far, I have tried only ChatGPT extensively (plus a bit of perplexity), so I will also try Grok next. Thanks very much!
EDIT: I’ve looked at your output of Grok above, and the conclusion seems completely opposite… After all, the key point seems the interpretation of the word “use” in the document. Grok says:
The identifier is used (it appears in the USE statements), and the entities are not generic interfaces, so the program is non-conforming.
and I think the above interpretation is opposite to that of ChatGPT above.
To be more specific, I’ve added the link for the full output of ChatGPT in my first post above.
Grok seems to agree that it was wrong and ChatGPT was correct: https://grok.com/share/bGVnYWN5_b22ed10a-66b7-40bc-a92c-eb74fe8a3468. But I don’t know, I don’t trust AI to this extent, that’s why I didn’t post it initially. But at least the quotes are correct.