generic type bound proc with bibding in a base class

[MR]

Hi,
   ifort does not compile the following code because:

ifort -c m.f90
m.f90(15): error #8423: In GENERIC type bound procedure definition each binding name must be the name of a specific binding of the type.   [FF]
  generic :: gen_f => ff
----------------------^
compilation aborted for m.f90 (code 1)

I wander whether this error is correct, since I would expect the
procedure ff to be equally available in t1 and t2 - but I must say
that I don't know what the standard says about this.

ifort -V
Intel(R) Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 14.0 Build 20140120

module m

 implicit none

 private

 type, abstract :: t1
 contains
  !generic :: gen_f => ff ! works
  procedure, pass(this) :: ff
 end type t1

 type, abstract, extends(t1) :: t2
 contains
  generic :: gen_f => ff ! does not work
 end type t2

contains

 subroutine ff(this)
  class(t1) :: this
   ! do nothing
 end subroutine ff

end module m

[Steven_L_Intel1]

I am inclined to agree with you that this code is legal. I will pass this on to the developers and let you know of any progress. Issue ID is DPD200256336.

[FortranFan]

I don't know if such a thing is allowed by the standard, but gfortran 4.9 allows it.

But it doesn't "feel right" to do something like this though - I'd personally shy away from it in my code as I'd greatly struggle trying to understand it if I've to revisit it at any later stage.  This is especially the case since the standard grants the facility to add to a generic in extended types.

What is your use case for this?

[MR]

Steve, than you for checking.

FortranFan: I think that classes are built on top of each other very much like modules, so generic procedures have the same pros and cons: sometimes they help and sometimes (often?) they hide useful information.

In my small example, the net effect is making ff available also under the name gen_f. A more complicated case would be a base class with a constructor which must be overloaded for a derived class.

Marco

[FortranFan]

Marco wrote:

.. classes are built on top of each other very much like modules, so generic procedures have the same pros and cons: sometimes they help and sometimes (often?) they hide useful information.

In my small example, the net effect is making ff available also under the name gen_f. A more complicated case would be a base class with a constructor which must be overloaded for a derived class.

..

No, I find generics to be very helpful and use them all the time - there are hardly any cons with them in my book.

Instead I was referring to your specific approach of binding a procedure "contained" in a "base" derived type to a generic that gets specified only in an extended type.  In your example above, why can't you simply do as follows?

   MODULE m
   
      IMPLICIT NONE
   
      PRIVATE
   
      TYPE, ABSTRACT :: t1
   
      CONTAINS
   
         GENERIC :: gen_f => ff
   
         PROCEDURE, PASS(this) :: ff
   
      END TYPE t1
   
      TYPE, ABSTRACT, EXTENDS(t1) :: t2
   
      END TYPE t2
   
   CONTAINS
   
      SUBROUTINE ff(this)
   
         CLASS(t1) :: this
   
         !.. Do nothing
   
      END SUBROUTINE ff
   
   END MODULE m

Then, as I mentioned above, if you need to "extend" gen_f to cover other procedures contained in extended derived types, you can repeat generic :: gen_f => .. statements in those extended types.

So what I've is a design question: why you don't want the base definition of gen_f generic to be specified in t1 itself when ff is contained in there; why place it in t2?  That is, is there some advantage I'm not aware of?

[MR]

Instead I was referring to your specific approach of binding a procedure "contained" in a "base" derived type to a generic that gets specified only in an extended type.  In your example above, why can't you simply do as follows?

Yes, putting it in the base class would be a perfectly fine option, I agree. The point is, sometimes you can not change the base class, or sometimes the generic only makes sense in the extended class, so in these cases I see nothing bad defining it in the extended class. This also happens with module procedure: sometimes a module uses another one and overloads a subroutine, making it a generic one.