Generic procedures: non-ambiguous at declaration or use?

Generic procedures: non-ambiguous at declaration or use?

Consider this


    module generics

    Type T
    procedure :: A
    procedure :: B
    generic :: C=>A, B
    end type T

    subroutine A(X,Y,Z)
    class(T) X
    real Y
    real, optional :: Z
    end subroutine

    subroutine B(X,Y,Z)
    class(T) X
    class(*), optional :: Y, Z
    end subroutine

    end module generics 

The two subroutines are ambiguous (e.g. for C%(x,1.,2.)). But ifort accepts this when you compile the module, rejecting it only  if you try to use it in any way that is ambiugous. gfortran rejects it as soon as you compile the module. So when is non-ambiguity required? The standard doesn't seem to be very obviously clear on this.

For libraries it would be useful to have at least some compile-time warning that there may be ambiguous call cases.

6 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

The standard makes no mention of "when" - it simply says you are not allowed to have an ambiguous generic. But I agree it would be nice if the compiler could alert you as soon as if the problem is seen. I'll suggest that to the developers.

There is a case where it's not possible to know until use - if modules mod1 and mod2 each add a routine to the same generic, either one by itself is fine but if a program then uses both modules, it's still not an issue unless the generic is used.

Steve - Intel Developer Support

Strictly speaking, the Fortran standard only requires Fortran compilers to report violations of the numbered syntax rules and associated constraints.  However, Fortran compilers may report additional violations of the rules that are in the normative text but not in the numbered syntax rules and constraints.


Doesn't this come down to what the scope of the generic identifier is?  Isn't it in scope inside the type definition?  Doesn't C1215 (in F2008) then require a diagnostic, even if the generic name isn't then used?

Isn't the "doesn't matter unless it is used" a separate aspect around conflicting "identifiers", rather than generic disambiguation?  Is a writing style that involves a whole heap of semi-rhetorical questions really annoying?

I'm not sure, but I'd guess "yes" to all the above.

To that last question, definitely yes.

I'd have to think a bit more on the scope issue, but I now agree with you that C1215 requires the diagnostic when the ambiguity is visible. The matter is perhaps a bit different (and more restricted) when one is considering generic TBPs, but I think you could get into this situation with extending a type - not 100% sure of that.

Steve - Intel Developer Support

Leave a Comment

Please sign in to add a comment. Not a member? Join today