modules and explicit interfaces again....

[andrew_4619]

Having now FULLY embraced the awesome wonderfulness of modules in recent times I have a question.

100% of my routines are Contained within various modules. When writing a new piece of code, first base is getting it to compile without error or warning. Any external FUNCTION that is referenced must have a USE (or USE, only:) entry, if not it is undeclared and will generate and error /warning. So far so good, with no errors or warnings we move on the building any dependant code, and then we link, all of which may take some time.

We then get link errors (unresolved) as we have referenced SUBROUTINES in the new code which have not been exposed by USE or are protected by PRIVATE. It would be useful if there was a compiler flag to treat SUBROUTINES in the same way as functions and generate this error on compilation, as this would save time. Does such an option exist already?

[bmchenry]

I think that is correctly a linker issue since it compiles properly and not until the link step will the process try to 'find' the routines. Similar to linking to system and external Dlls, until you try to link things the program doesn't care whether they are available, just that they are properly defined.

[andrew_4619]

@bmchenry I think you are missing the point. I only have explicit interfaces. If the interface for a function is not exposed I can get a diagnostic, for the error, why not the same for  a subroutine? Sure that can only be an option not an absolute requirement but there is no reason why it could not be so. It would save time during development which is surely a key function of a good compiler.

I suppose it could be summarised as "EXPLICIT ALL" rather than "IMPLICIT NONE"

[Steven_L_Intel1]

No such option exists at present. It has been suggested, and there has been some discussion on the standards committee for syntax similar to IMPLICIT NONE. There was general support for the idea but my recollection is that other work items for the next standard were considered more important. I have suggested to our developers that some sort of compiler option that requires an explicit interface for all procedure references would be nice to have.

[qolin]

There is an easy way to get what you want: specify at least one argument in the call statement(s) using keyword syntax. Keywords are illegal without an explicit interface, so the absense of this causes a compile-time error. The only problem is remembering to do this on enough of the CALLs...

[andrew_4619]

Interesting thought qolin but if I remembered to do that I would have remembered to USE the module that interface required.....

[FortranFan]

app4619 wrote:

@bmchenry I think you are missing the point. I only have explicit interfaces. If the interface for a function is not exposed I can get a diagnostic, for the error, why not the same for  a subroutine? Sure that can only be an option not an absolute requirement but there is no reason why it could not be so. It would save time during development which is surely a key function of a good compiler.

I suppose it could be summarised as "EXPLICIT ALL" rather than "IMPLICIT NONE"

"EXPLICIT ALL" would be a cool addition!  It has a very positive ring to it..

[Steven_L_Intel1]

Here's the proposal that was discussed at the October 2013 meeting (I was not present). It was approved for inclusion in the next standard.

[FortranFan]

Steve Lionel (Intel) wrote:

Here's the proposal that was discussed at the October 2013 meeting (I was not present). It was approved for inclusion in the next standard.

Thanks, Steve - not as cool as app4619's suggestion but usable.

I wish such proposals also included "pseudo code" that would illustrate how the proposed feature would be used in actual practice, if ever implemented.  That is, a corollary to "a picture is worth a thousand words"!