Within a scoping unit, a procedure name is established to be generic if any of the following is true:
To resolve a reference to a procedure name established to be generic, the following rules are used in the order shown:
The reference must be consistent with one of the specific interfaces of the interface block.
The reference must be consistent with the interface of that intrinsic procedure.
Examples
The following example shows how a module can define three separate procedures, and a main program give them a generic name DUP through an interface block. Although the main program calls all three by the generic name, there is no ambiguity since the arguments are of different data types, and DUP is a function rather than a subroutine. The module UN_MOD must give each procedure a different name.
MODULE UN_MOD
!
CONTAINS
subroutine dup1(x,y)
real x,y
print *, ' Real arguments', x, y
end subroutine dup1
subroutine dup2(m,n)
integer m,n
print *, ' Integer arguments', m, n
end subroutine dup2
character function dup3 (z)
character(len=2) z
dup3 = 'String argument '// z
end function dup3
END MODULE
program unclear
!
! demonstrates how to use generic procedure references
USE UN_MOD
INTERFACE DUP
MODULE PROCEDURE dup1, dup2, dup3
END INTERFACE
real a,b
integer c,d
character (len=2) state
a = 1.5
b = 2.32
c = 5
d = 47
state = 'WA'
call dup(a,b)
call dup(c,d)
print *, dup(state) !actual output is 'S'only
END
Note that the function DUP3 only prints one character, since module UN_MOD specifies no length parameter for the function result.
If the dummy arguments x and y for DUP were declared as integers instead of reals, then any calls to DUP would be ambiguous. If this is the case, a compile-time error results.
The subroutine definitions, DUP1, DUP2, and DUP3, must have different names. The generic name is specified in the first line of the interface block, and in the example is DUP.