Interfaces and Generic Procedures

Analogy categoryAnalogies

Why Explicit Interfaces Matter

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.

🏏

Cricket analogy: An explicit interface is like the ICC's official playing conditions document specifying exact ball weight and pitch dimensions, so any ground hosting a match is automatically checked against the same known rules.

Interface Blocks for External Procedures

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.

🏏

Cricket analogy: Writing an INTERFACE block for a legacy external subroutine is like re-registering an old-format scorecard from a 1980s Test match into the modern digital scoring system so today's software can validate it.

Generic Interfaces and Operator Overloading

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.

🏏

Cricket analogy: A generic 'add' procedure resolving to different specific versions is like the term 'boundary' meaning either a four or a six depending on whether the ball crossed the rope on the bounce or on the full.

Optional and Keyword Arguments

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.

🏏

Cricket analogy: An OPTIONAL argument like tol is like a DRS review that a captain may or may not invoke; the umpire must check PRESENT(review) before acting, since assuming a review exists when none was called leads to a wrong decision.

Placing procedures inside a MODULE and USE-ing that module gives you explicit interfaces automatically, along with argument checking, OPTIONAL/keyword arguments, and array descriptor passing for assumed-shape arrays. This is why modern Fortran style strongly favors module procedures over old-style external subroutines compiled and linked separately.

Referencing an OPTIONAL dummy argument that was not supplied by the caller, without first checking PRESENT(), is undefined behavior. Always guard access with IF (PRESENT(tol)) THEN ... before reading an optional argument's value.

Explicit interfaces let the compiler validate argument types, kinds, ranks, and INTENT at every call site.
Module and internal procedures get explicit interfaces automatically; external subroutines need a manual INTERFACE block.
Assumed-shape arrays and POINTER/ALLOCATABLE dummy arguments require an explicit interface to be legal.
Generic interfaces (INTERFACE name ... MODULE PROCEDURE ...) dispatch one name to multiple type-specific implementations.
Operator overloading via INTERFACE OPERATOR(+) lets custom types use built-in operator syntax.
OPTIONAL arguments require a PRESENT() check before being referenced inside the procedure.
Keyword arguments improve call-site readability and let callers supply arguments out of order by name.