ISO/IEC JTC1/SC22/WG5/N1365 Interface Scoping Problem ========================= 1. The problem in F90/F95 MODULE M TYPE T PRIVATE ... END TYPE CONTAINS SUBROUTINE SUB(X,F) TYPE(T) X(10) INTERFACE TYPE(T) FUNCTION F() ! Oops DIMENSION F(10) END END INTERFACE X = F() END SUBROUTINE END i.e. A module procedure inside the module that defines an "opaque" type cannot have a dummy procedure that has an argument of that type (assuming that an explicit interface is required for the dummy function). 2. The problem in F200x ... obstructs the use of certain O.O. constructs. MODULE M TYPE T PROCEDURE(xyz),PASS_OBJ,POINTER :: p ! (Alpha) CONTAINS PROCEDURE,PASS_OBJ :: x => mpx PROCEDURE(xyz),PASS_OBJ :: y => NULL() ! (Beta) END TYPE ... INTERFACE PROCEDURE() SUBROUTINE xyz(obj) CLASS(T) obj ! Oops END SUBROUTINE END INTERFACE ... CONTAINS SUBROUTINE mpx(obj) CLASS(T) obj ! ok ... END SUBROUTINE END The problem is that the "PROCEDURE(xyz)" requires the abstract interface to be defined in the same module, but the interface cannot access the type T which it needs to declare the dummy arguments. This applies to any procedure pointer (or deferred type-bound procedure) that has a dummy argument of the type, not only to PASS_OBJ procedures. "Beta" can be simulated by the user - by providing a stub procedure instead of a NULL() - but "Alpha" cannot be done in that way. 3. The Proposal ... is to provide a means of accessing host entities from an interface body. Syntax: IMPORT [::] e.g. IMPORT mytype,yourtype This would access the named entities only, from the enclosing scoping unit. The IMPLICIT mapping would not be imported. Thus to fix up the example in section 2 above, the user would put "IMPORT T" immediately before the line containing "Oops". 4. Further Details The IMPORT statement would only be allowed in interface bodies and would appear after any USE statements and before any IMPLICIT statement. It is not considered to be useful to be able to rename entities in this limited context, so a simple is thought to be adequate.