Interfaces and Generic Procedures

An explicit interface tells the compiler the exact signature of a procedure, including argument types, kinds, ranks, and INTENT, so it can validate every call site at compile time. Procedures defined inside a MODULE, or inside the CONTAINS section of a program unit, automatically have explicit interfaces wherever they are used (as internal or module procedures), but a standalone external subroutine compiled separately has only an implicit interface unless you write an INTERFACE block for it, meaning mismatched argument counts or types can silently corrupt memory instead of failing to compile.

For a legacy external subroutine like SUBROUTINE solve(a, b, n), you write an explicit INTERFACE block mirroring its signature and place it in the calling scope (often inside a module), which lets the compiler check the call exactly as it would a module procedure. This is especially important for array arguments with assumed-shape (a(:)) or POINTER/ALLOCATABLE dummy arguments, which require an explicit interface to be legal at all, since the compiler must pass extra descriptor information (bounds, stride) that implicit-interface calling conventions cannot carry.

A generic interface lets one name dispatch to different specific procedures based on argument types, kinds, or ranks, declared with INTERFACE add ... MODULE PROCEDURE add_int, add_real ... END INTERFACE, so calling add(x, y) resolves at compile time to whichever specific version matches. The same mechanism underlies operator overloading: INTERFACE OPERATOR(+) bound to a module procedure lets you write v1 + v2 for two TYPE(vector3) operands and have it call your custom addition routine, and Fortran 2003's GENERIC keyword lets you attach generic names directly to type-bound procedures for polymorphic-feeling dispatch without inheritance.

Explicit interfaces also enable OPTIONAL dummy arguments and keyword-based calling, so a procedure like SUBROUTINE solve(a, b, tol) with tol declared OPTIONAL, INTENT(IN) can be called either as CALL solve(a, b) or CALL solve(a, b, tol=1e-6), and inside the procedure you must test PRESENT(tol) before referencing it, since an absent optional argument is undefined if accessed directly. Keyword arguments (CALL solve(b=bvec, a=amat)) improve readability at call sites with many parameters and let callers skip earlier optional arguments while supplying a later one by name.