References to Generic Names

Within a scoping unit, a procedure name is established to be generic if any of the following is true:

The scoping unit contains an interface block with that procedure name.
The procedure name matches the name of a generic intrinsic procedure, and it is specified with the INTRINSIC attribute in that scoping unit.
The procedure name is established to be generic in a module, and the scoping unit contains a USE statement making that procedure name accessible.
The scoping unit contains no declarations for that procedure name, but the procedure name is established to be generic in a host scoping unit.

To resolve a reference to a procedure name established to be generic, the following rules are used in the order shown:

If an interface block with that procedure name appears in one of the following, the reference is to the specific procedure providing that interface:
1. The scoping unit that contains the reference
2. A module made accessible by a USE statement in the scoping unit
The reference must be consistent with one of the specific interfaces of the interface block.
If the procedure name is specified with the INTRINSIC attribute in one of the following, the reference is to that intrinsic procedure:
1. The same scoping unit
2. A module made accessible by a USE statement in the scoping unit
The reference must be consistent with the interface of that intrinsic procedure.
If the following is true, the reference is resolved by applying rules 1 and 2 to the host scoping unit:
1. The procedure name is established to be generic in the host scoping unit
2. There is agreement between the scoping unit and the host scoping unit as to whether the procedure is a function or subroutine name.
If none of the preceding rules apply, the reference must be to the generic intrinsic procedure with that name. 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 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
 !
 ! shows 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.