08-262
To:       J3
From:     Van Snyder /INTERP
Subject:  Revisiting F03/0071
Date: 2008 August 11

NUMBER: F03/0071
TITLE: Subroutine/function ambiguity in generics
KEYWORDS: subroutine, generic, implicit
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting

QUESTION:

 Q1. Is the following generic allowed?

     interface q
       subroutine qr(f)
         implicit real(f)
         external f
       end subroutine
       subroutine qc(f)
         implicit complex(f)
         external f
       end subroutine
     end interface q

     The uncertainty arises because it is not established
     whether F is a subroutine or a function. If either F
     were a subroutine, then it would be clear that the
     generic was disallowed. One might be able to use this
     to deduce that both Fs must be functions. This seems
     like an obscure deduction to demand of the compiler.

 Q2. Consider the following "obviously" allowed generic

     module m
       interface q
         subroutine qr(f)
           real, external :: f
         end subroutine
         subroutine qc(f)
           complex, external :: f
         end subroutine
       end interface q
     end module m

     Is the following main program valid?

     program main
       use m
       external ff
       call q(ff)
     end

     Again, the problem is that it is unclear whether or not
     ff is a function or subroutine. If it is a subroutine,
     then the call is ambiguous. One might thus deduce that
     ff must be a function, and therefore of type real,
     but this seems like an obscure deduction to demand of
     the compiler.

ANSWER:

1. The program fragment is not conforming.  A generic interface is
   required to be nonambiguous.  This is a similar situation to the
   declaration of an external procedure in a module, where a procedure
   that is a function is required to have its type and type parameters
   explicitly declared.  An edit is provided to require this for
   specific procedures in a generic interface.

2. The main program program unit is conforming, although the program
   would not be if the external procedure FF were not in fact a real
   function.  If the reference had been to QR instead of Q, it would be
   clear that FF has to be a real function, from the point of view of
   the main program scoping unit.  At the call site, the reference to Q
   is known to be a reference either to QR or QC (the interface block
   for Q is not defective), both of which require a function actual
   argument.  FF is known to be either a subroutine or a function, since
   it explicitly has the EXTERNAL attribute, and if it is a function it
   is known by implicit typing rules to be real.  Because neither
   specific in the generic allows a subroutine as an argument, FF must
   therefore be a function.  Since FF is real, QR is called.  (The
   generic cannot have a specific that accepts a subroutine as an
   argument, as that would violate the requirements in 16.2.3.)

EDITS:

[261:3] In 12.3.2.1 Interface block,
  immediately after "A generic interface is always explicit.",
  append new sentence to paragraph
    "If a specific procedure in a generic interface has a function
     dummy argument, that argument shall have its type and type
     parameters explicitly declared in the specific interface."
{I.e. if you just say EXTERNAL dummy, you must mean a subroutine.}

SUBMITTED BY: Richard Maine

HISTORY: 05-265    m174  F03/0071 Submitted
         08-189r1  m184  Answer provided - Passed by J3 meeting
         08-213    m185  In J3 letter ballot #17, failed
         08-xxx    m185  Revised answer 2.