Wondering if anyone else things something along the lines of the following language enhancment proposal would be reasonable/desirable, or if preprocessing or proposed templating features would make it unneccessary …
You can USE the two modules A and B in module C as long as you do not
reference anything with a conflict. It would be very useful (at least for me) if an
automatic interface were created for non-conflicting procedures instead
of having to rename them and manually create interfaces.
A use case would be where one has hundreds of duplicate routines that
are included into the two modules A and B, where module A defines a type
of REAL for WP, and module B defines WP as double precision.
This lets you create a single and double precision version of all the
routines just using INCLUDE. No preprocessing or templating is required.
Now USE A and B in module C (which is allowed now as long as nothing
with a conflict is used).
With the change to build automatic interfaces (which I thought actually
occurred, could swear I did this in the past) a user could just then
use module C and have all the procedures accessible as generics without
having to build interfaces.
The effort saved is considerable when hundreds of procedures are being
created from the included files.
A simplistic skeleton proposing what would then work:
module A
implicit none
private
public subx
integer,private,parameter :: wp=kind(0.0e0)
contains
subroutine subx(x) ! begiining of include subx.inc
real(kind=wp) :: x
write(*,*)'suba',x
end subroutine subx ! end of include of subx.inc
end module A
module B
implicit none
private
public subx
integer,private,parameter :: wp=kind(0.0d0)
contains
subroutine subx(x) ! begiining of include subx.inc
real(kind=wp) :: x
write(*,*)'subb',x
end subroutine subx ! end of include of subx.inc
end module B
module C
use A
use B
implicit none
private
public subc
public subx
contains
subroutine subc()
call subx(1.0) ! <-- currently not allowed
call subx(2.0d0) ! <-- currently not allowed
end subroutine subc
end module C
program testit
use C
call subc()
call subx(3.0) ! <-- currently not allowed
call subx(4.0d0) ! <-- currently not allowed
end program testit
Something more explicit but brief, indicating you wanted to generate
such interfaces could eliminate issues with data and unintentional use.
Perhaps a variation of INTERFACE that allowed specifying USE statements
or a new USE syntax, such as
USE (A,B)
which would indicate A and B should be used to build the generic interface
would be less likely to have unintended consequences.
Since you can currently include modules with conflicts as long as you do not reference the conflicting entities it seems the compiler must be relatively close to being able to handle this already (perhaps).