Forcing explicit subroutine interface compliance?

[David_Hittner]

Is there some way to tell the compiler that all called subroutines *must* have their interfaces declared explicitly, either through a USE statment or an INTERFACE statement, to ensure API compliance at compile time (similar to ANSI C Prototypes)?

Also, if a command line switch to enable explicit interface checking exists, is there also a CDEC$ way of forcing it?

[jimdempseyatthecove]

I did not ask if they should, I asked if there were any implications (of interface enforcing) related to statement functions.

While I know statement functions "should" be converted into actual functions, this may not be practical with programs with a heritage going back 20, 30, 40, years. "If it ain't broke - don't fix it". This said, if you can afford to modernize your code, inclusive of regression testing, and if this will save on future work (IOW see a return on your investment), then by all means make the changes. Though your code may not go back this far, with Fortran (FORTRAN), and following the advice of keeping current, you may have had to rework your code 12 times (8 times if you start at FORTRAN IV, though some on this forum start at FORTRAN 66 or 77).

Jim Dempsey

[TimP]

Statement functions don't support explicit interfaces.  As Steve mentioned above, it appears the F15 option to require explicit interface wouldn't apply to statement functions.  

30 years ago and beyond, compilers had some odd extensions in permitted usage of statement functions.  I was mislead into thinking that what worked with both Honeywell and CDC was fairly standard, since those compilers didn't share many non-standard extensions.  A fairly common extension was to permit identifiers to act as generic types, with name replacement not affecting the original data type.  F77 made it clear that this was non-standard, but it took another decade for some compilers to settle down.

There are several contexts where statement functions technically aren't permitted together with F90 syntax but most compilers permit them.  I'm not certain whether setting standards checking catches all of them.

ifort at first sometimes had better optimization of statement functions than of internal procedures, but normally there has been no performance difference for years.  gfortran went the other way; internal procedures perform better.

[Steven_L_Intel1]

There's quite a bit of difference between statement functions and "ordinary" functions. You can't declare an interface for statement functions. The dummy arguments get their types (and type parameters) from implicit typing or that of the same-named variable in the current scope, but no other attributes. When you reference a statement function, any actual arguments are converted to the dummy's type according, so you can have mismatches (integer to real, etc.) which you can't do with explicit interfaces.

As I said, any enforcement of explicit interfaces will completely ignore statement functions. Here is what F2015 says about IMPLICIT NONE (EXTERNAL):

C593 If IMPLICIT NONE with an implicit-none-spec of EXTERNAL appears within a scoping unit, the name of an external or dummy procedure in that scoping unit or in a contained subprogram or BLOCK construct shall be explicitly declared to have the EXTERNAL attribute.

Statement functions are neither external nor dummy procedures. Note that IMPLICIT NONE(EXTERNAL) will still allow you to have implicit interfaces as long as you declare the name EXTERNAL explicitly.

[andrew_4619]

Any ideas when we are likley to see implicit none (external)?