Private procedure 'visible' in extending type

[Bálint_A_]

Dear all,

I think the ifort 16.0.3 (the most recent version I have access to right now), does not handle private procedures correctly. The example below demonstrates the issue. The Base type declares a private type bound procedure. This should not be visible in any sense in the extending type Extended in my opinion. The compiler refuses to compile the code, claiming that 'An overriding binding and its corresponding overridden binding must have the same number of dummy arguments.' But this is contradictory IMO as the procedure in the Base type is private, and should, therefore, not be be visible outside of it. Therefore, it can not be overriden, so that type bound procedures in extending types may have the same name but different calling signature.

Best regards,

Bálint

module basemod
  implicit none
  private

  public :: Base

  type :: Base
    integer :: id
  contains
    procedure, private :: dummy
  end type Base

contains

  subroutine dummy(this, id)
    class(Base), intent(inout) :: this
    integer, intent(in) :: id

    this%id = id
    print *, 'Base'

  end subroutine dummy

end module basemod


module extmod
  use basemod
  implicit none

  type, extends(Base) :: Extended
  contains
    procedure, private :: dummy
  end type Extended

contains

  subroutine dummy(this)
    class(Extended), intent(in) :: this

    print *, 'Extended'

  end subroutine dummy

end module extmod

[Steven_L_Intel1]

I just had a chat with the development team lead and he is deferring the fix for the issue reported in the original post until the next major version (second half of 2017). The reason is that our test system, with many tests from customers, had a lot of failures from code that assumed such references were valid. We don't want to have to explain to a lot of upset customers that we deliberately broke their code in a minor update, even if we can point to the standard for backing.

[FortranFan]

Steve Lionel (Intel) wrote:

I just had a chat with the development team lead and he is deferring the fix for the issue reported in the original post until the next major version (second half of 2017). The reason is that our test system, with many tests from customers, had a lot of failures from code that assumed such references were valid. We don't want to have to explain to a lot of upset customers that we deliberately broke their code in a minor update, even if we can point to the standard for backing.

Steve,

Re: "the development team lead .. is deferring the fix for the issue .. until the next major version (second half of 2017)".  That's most unfortunate, I feel.  If Intel Fortran team is fully convinced the fix is COMPREHENSIVE and CORRECT relative to the standard revision (corrigendum in this case), then I think Intel should make it available right away to customers as part of /standard-semantics, or some such 'umbrella' option in the compiler that ensures full compliance with the Fortran standard.

Please note there are customers for whom standard compliance is paramount which also means adapting to revisions and reinterpretations and corrigenda and like.  So if the compiler starts rejecting code that was previously accepted that will be just fine with us as long as it is clear the revised compiler is fully compliant with the standard.

We're concerned the intended timeline for the above fix is now more than a year away and who knows, given budgetary constraints on compiler licensing and support renewals, in our situation the fix may end up several years down the round.  One can only venture a guess how much code might potentially get developed that will later be realized to be non-conforming with the standard.

[Steven_L_Intel1]

FortranFan, I sympathize, really I do. But we also have to be concerned about the reaction of our many commercial customers whom would take great exception to a minor update breaking their code because we started enforcing a restriction in the standard. Most customers assume that minor updates won't intentionally create breaking changes in semantics - they are (somewhat) more forgiving of such changes in new major versions, especially as we have months-long beta tests of the new versions. That we found so many tests, taken from customer code, that broke with this change makes us unwilling to put the change into a minor update.

We will, as usual, have a free beta test of next year's version starting early in the year. You'll be able to try it out then.

[FortranFan]

Steve Lionel (Intel) wrote:

FortranFan, I sympathize, really I do. But we also have to be concerned about the reaction of our many commercial customers whom would take great exception to a minor update breaking their code because we started enforcing a restriction in the standard. ..

Steve,

Thanks but it will be nice if the fix were included in the compiler soon (compiler 17, update 1?) but made effective only with some temporary switch (something that Intel has done in the past), say /assume_f08_0052.  Then when Intel thinks the time is right, the change can become the default.  This way, the other commercial customers are not affected while those wish to remain on the 'bleeding edge' of the standard (like my org) can avail themselves of the change much sooner..

[Principe__Javier]

Dear all,

What about variables? Should they be visible in the extension of a type made in a separate module? 

Consider the code:

module A_names
  implicit none
  private
  type :: A_t
     private
     integer :: a
  end type A_t
  public :: A_t
end module A_names

module two_names
  use A_names
  implicit none
  private

  type, extends(A_t) :: B_t
     private
     integer :: a 
  end type B_t
  public :: B_t

end module two_names

I'm getting this error (also using ifc 18, not shown below):

$ ifort --version

ifort (IFORT) 17.0.1 20161005
Copyright (C) 1985-2016 Intel Corporation.  All rights reserved.

$ ifort -c vars.f90
vars.f90(18): error #8205: A component declared in an extended type cannot have the same name as any accessible component of its parent type.  
     integer :: a 
----------------^
compilation aborted for vars.f90 (code 1)