To: J3                                                 10-129
From: John Reid
Subject: Interp F03/0071
Date: 2010 February 16
References: WG5/N1805, WG5/N1816, J3/09-007r3


DISCUSSION

Interp1 recommends that Interp F03/0071 be accepted and the
corresponding edit be made to J3/09-007r3. The interp is appended.

Edit to J3/09-007r3

[283:5] In 12.4.3.4.1 Generic idnetifiers, 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."

..............................................................


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

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-259    m185  Failed J3 letter ballot #17 08-213
         08-262    m185  Passed by J3 meeting
         09-187r2  m188  Passed J3 letter ballot #18 09-155

F2008 note: edit is 09-007r1 [285:5+] 12.4.3.4.1 "Generic identifiers"
  after "A generic interface is always explicit." - edit not passed as
  of m188