The code shown below does not trigger a compile/link time error; it does not trigger an error at runtime either. I am puzzled by several things here:
Does this mean that ensuring matching interfaces when using procedure pointers is the sole responsibility of the developer? But if yes, then why does (2) above leads to an error (as it should)?
FUNCTION F(X,Y) IMPLICIT NONE INTEGER F,X,Y F = X+Y END FUNCTION F PROGRAM MAIN IMPLICIT NONE ABSTRACT INTERFACE FUNCTION G(X) IMPLICIT NONE INTEGER G,X END FUNCTION G END INTERFACE PROCEDURE(G),POINTER :: FUN => NULL() PROCEDURE(G) :: F FUN => F !WRITE(*,*) FUN('a') WRITE(*,*) FUN(1) END PROGRAM MAIN
Generated interface checking currently gets activated only when you reference a procedure that has an implicit interface. Yes, it is your responsibility to ensure that the interface matches. Your item 2 occurs because the function reference conflicts with the explicit interface that is visible.
It would be an interesting extension to also check explicit interfaces against separate procedures, but the primary purpose of the feature was to help find errors in old, Fortran 77-style code without explicit interfaces.
ok - thanks Steve, I got it: the only check performed for the call on line 20 is the consistency with the abstract interface explicitly defined above; not with the external function.
Yes it would be nice to have a check against the interface of separate procedures - it seems all the information is readily available.
A possible problem with extending this is that I've seen quite a few programs, including some I wrote myself, where the explicit interface is deliberately different from the external procedure.
I will file a feature request for this.