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?
>>Perhaps Jim can elaborate on what he means by "interface enforcing"
! integer :: i ! not defined
integer(4) :: i4, i4Too
integer(8) :: i8, i8Too
StatementFunction(i) = i*i ! ?? is this valid as type of i not defined
SecondStatementFunction(i4) = i4*i4 ! ?? does this imply/require integer(4)
i4Too = 1234
i4 = SecondStatementFunction(i4Too) ! should be valid as types match
i8Too = 5678
i8 = SecondStatementFunction(i8Too) ! ?? should be invalid as types do not match
*** Note, I am not stating what is or is not valid. Just clarifying for FortranFan
Thanks, Jim, but again, I'm not sure if you're suggesting Intel Fortran compiler to provide some enforcement for statement functions. For Fortran standard has clearly made its intent clear by marking statement functions as obsolescent. So all those codes out there that still might have statement functions can either with live with the situation that they have tolerated all these years (no interface checking and no enforcement) or move on to something different, perhaps contained procedures as recommended by the standard. In your experience, how large you reckon is the FORTRAN code base that still makes use of statement functions? I personally have only come across one program (huge, commercial simulation code) that made use of statement functions and that was many years ago; surprisingly, the vendor had on their own decided to do away with statement functions and replaced them with another approach that obviated the need.
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).
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.
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.