(j3.2006) Abstract types, deferred bindings, generic bindings

Rafik Zurob rzurob
Fri Oct 2 21:43:18 EDT 2015


I think it is sufficient to have generic binding S only in type A in this 
case.

> If it's only in the parent type, and I have a variable V of type (not
> class) B, can I reference V%S?

I don't see why not.  It's the same as referencing V%S_d or V%S_a.

> If it's only in the extensions, and I have a variable W of class(a), can
> I reference W%S?

No.  S would not be part of type A.  You would need SELECT TYPE with a 
type guard that gives you access to type B.

> Is the "generic" statement allowed in both type definitions? (One of my
> compilers says that's ambiguous.)

The two generic statements in type A and its extension are specifying the 
same specific bindings.  So you can reduce the problem to whether you can 
repeat a specific binding name in the a generic binding or not.  i.e. The 
same issue can occur without type extension:

type Mytype
contains
  procedure foo
  generic :: g => foo, foo  ! error?
end type

Section 12.4.3.5.5 says: "C1220 Within the scope of a generic name, each 
pair of procedures identified by that name shall both ...".  If you read 
"each pair of procedures" to mean each pair of procedure *names* appearing 
in the generic interface, then you have to apply the rules in 12.4.3.5.5 
to the pair (foo, foo) and it will be found ambiguous.  If, however, you 
read "each pair of procedures" to mean each pair of [unique] procedures, 
then the interface is unambiguous.  Interp F03/0018 clarified that the 
latter is the intended approach.  i.e. Generic bindings can have duplicate 
specific procedure names.

For what it's worth, XLF accepts your example, if I remove the :: from 
"module :: M".

Regards

Rafik

j3-bounces at mailman.j3-fortran.org wrote on 02/10/2015 08:12:59 PM:

> From: Van Snyder <Van.Snyder at jpl.nasa.gov>
> To: j3 <j3 at j3-fortran.org>
> Date: 02/10/2015 08:13 PM
> Subject: (j3.2006) Abstract types, deferred bindings, generic bindings
> Sent by: j3-bounces at mailman.j3-fortran.org
> 
> Consider such a module:
> 
> module :: M
> 
>   type, abstract :: A(rk)
>     integer, kind :: RK
>   contains
>     procedure(s_d), deferred :: S_d
>     procedure(s_s), deferred :: S_s
>     generic :: S => s_d, s_s
>   end type A
> 
>   type, extends(a) :: B
>   contains
>     procedure :: S_d => s_d_2
>     procedure :: S_s => s_s_2
>     generic :: S => s_d, s_s
>   end type B
> 
>   abstract interface
>     subroutine S_d ( X )
>       import
>       integer, parameter :: RK = kind(0.0d0)
>       class(a(rk)), intent(inout) :: X
>     end subroutine S_d
>     subroutine S_s ( X )
>       import
>       integer, parameter :: RK = kind(0.0e0)
>       class(a(rk)), intent(inout) :: X
>     end subroutine S_s
>   end interface
> 
> contains
> 
>     subroutine S_d_2 ( X )
>       integer, parameter :: RK = kind(0.0d0)
>       class(b(rk)), intent(inout) :: X
>     end subroutine S_d_2
>     subroutine S_s_2 ( X )
>       integer, parameter :: RK = kind(0.0e0)
>       class(b(rk)), intent(inout) :: X
>     end subroutine S_s_2
> 
> end module M
> 
> Is the "generic" statement allowed in both type definitions? (One of my
> compilers says that's ambiguous.)
> 
> If not, should it be in the parent type, or each extension?
> 
> If it's only in the parent type, and I have a variable V of type (not
> class) B, can I reference V%S?
> 
> If it's only in the extensions, and I have a variable W of class(a), can
> I reference W%S?
> 
> I would have preferred that we hadn't required the interface-name on the
> procedure statement with the deferred attribute if the binding-name is
> the name of an accessible abstract interface, i.e., if C482 were instead
> 
> C482 (R452) If DEFERRED appears and <binding-name> is not the name of an
>      abstract interface [or a procedure that has an explicit
>      interface]?, <interface-name> shall appear.
> 
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3
> 





More information about the J3 mailing list