- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Consider this
module generics
Type T
contains
procedure :: A
procedure :: B
generic :: C=>A, B
end type T
contains
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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page