Will this hurt, Doc?

[OP1]

In the code below the PROC deferred binding appears in both U and V (which extends U).

It's probably benign, in the sense that it does not seem it would do anything; but it is strange nonetheless and I am wondering if this is something that the compiler (classic ifort from OneAPI) should catch.

MODULE M
IMPLICIT NONE

TYPE, ABSTRACT :: T
    CONTAINS
        PROCEDURE(T_PROC),DEFERRED :: PROC
END TYPE T

TYPE, EXTENDS(T), ABSTRACT :: U
    CONTAINS
        PROCEDURE(U_PROC),DEFERRED :: PROC
END TYPE U

ABSTRACT INTERFACE

    SUBROUTINE T_PROC(SELF)
    IMPORT :: T
    IMPLICIT NONE
    CLASS(T) :: SELF
    END SUBROUTINE T_PROC

    SUBROUTINE U_PROC(SELF)
    IMPORT :: U
    IMPLICIT NONE
    CLASS(U) :: SELF
    END SUBROUTINE U_PROC

END INTERFACE

END MODULE M

[Steve_Lionel]

"If a specific type-bound procedure specified in a type definition has the same binding name as an accessible type-bound procedure from the parent type then the binding specified in the type definition overrides the one from the parent type." (F2018 7.5.7.3p1)

[JohnNichols]

@Steve_Lionel  so for reasons I do not understand and neither does the Oracle at Delphi - your message had a translate button on it - I have not noticed this before. 

So I hit the button and picked Finnish, one of these rare languages not IndoEuropean - you quoted 

"jos tietyllä tyyppimäärityksessä määritetyllä tyyppiin sidotulla toimintosarjalla on sama sidontanimi kuin päätyypin käytettävissä olevalla tyypillä sidotulla toimintosarjalla, tyyppimäärityksessä määritetty sidonta ohittaa päätyypin sidonnan." (f2018 7.5.7.3p1)

All I can say is interesting, last time I was in Finland everyone spoke English to me. 

[OP1]

@JohnNichols I may be the first one to call you out on this, but your annoying off-topic ramblings on this forum rarely bring any value to the discussions. There you go.

[OP1]

Thanks Steve.

After thinking about it for a while, I found a possible use case of that scenario.

Assume T is an abstract type with a deferred binding PROC.
Assume U is a concrete extension of T (and thus, it features a type-bound procedure for the deferred implementation of PROC).
Assume V is an abstract type extending U with a deferred binding PROC which interface matches the deferred binding PROC of T (safe for the type of the passed object of course).

In this approach, all immediate concrete extensions of V will be forced to implement PROC again, which may be desirable.

In fact, if you indulge me for a moment here, it would be nice though if we could define in an abstract type a deferred binding that must be explicitly implemented in every concrete extension of the type. Something like:

TYPE, ABSTRACT :: T
    CONTAINS
        PROCEDURE(T_PROC), DEFERRED, MANDATORY :: PROC
END TYPE T

This would not bring any new capability to the language of course; but it would provide a nice compile-time check for the developer to make sure that all concrete extensions of T do feature a (non-inherited) type-bound implementation of PROC. Absent this, it is extremely easy (in large codes) to 'forget' to implement PROC for some extensions of T (when they inherit PROC from a parent).

[Steve_Lionel]

All the posts have that button.

[FortranFan]

@OP1 wrote:
..
Assume T is an abstract type with a deferred binding PROC.
Assume U is a concrete extension of T (and thus, it features a type-bound procedure for the deferred implementation of PROC).
Assume V is an abstract type extending U with a deferred binding PROC which interface matches the deferred binding PROC of T (safe for the type of the passed object of course).
..

Based on what I recall, type definition for V will not conform to the language standard which places restrictions on the DEFERRED attribute with type bindings.

[JohnNichols]

@OP1  - 

We are each entitled to our opinions. You are entitled to yours and I respect your right to express it.  I also respect the 1,354,664 humans, men and women who died, for your right to express a free opinion, in the US Military since Concord Green.  Average age 24 probably. 

You are not the first to express an opinion on my thoughts, nor will you be the last, at least one was quite nice, although private. 

The forum is Intel Fortran Compiler, and by extension, the system it works on as many have complained of the website in its current form. 

I think it is a good website and that the people here are human and tend to be polite.  Perhaps a tad obsessed with Fortran. 

At the end of a long day, using the Intel Fortran compiler to study a difficult problem of improving infant mortality in the USA, I am currently revising a paper on this topic for a major journal, it is nice to blow off a bit of steam on this forum, with people who I consider I am on friendly terms with, including those who send nice private messages. 

I use Intel Fortran Compiler every day to study problems leading to death of humans and ways to stop it.  It is no always fun, and the ethical arguments can get intense. 

But, you have the simple task of not reading them. Your post reminded me of one of the funniest books every written, Redheap, a children's story that was banned in Australia in 1934, I read the note inside the banned book provided by the censors, and it made no modern sense, but clearly the censors looked at that from the 1934 perspective.   I also read the book at 13 and thought it was good humour. 

As I said, I appreciate your opinion, I am happy to converse with you privately at your convenience.  Finally, one of my students, active US Military Infantry, once returned to my uni and said, that funny story you told us in class, saved my life and that of my men, when I used it to get out of an ambush.  The story was not funny and it had a purpose to break up a boring lecture.  I am glad he and his men are alive, but talking about the English Channel, radio waves and bombers was not part of the curriculum, but it was important for one student anyway.

Censorship is a slippery slope and as John Donne remarked in the original 

No man is an Iland, intire of itselfe; every man
is a peece of the Continent, a part of the maine;
if a Clod bee washed away by the Sea, Europe
is the lesse, as well as if a Promontorie were, as
well as if a Manor of thy friends or of thine
owne were; any mans death diminishes me,
because I am involved in Mankinde;
And therefore never send to know for whom
the bell tolls; It tolls for thee.

 So I hope you have a nice day.  I will now return to Fortran and infant mortality.  It is not difficult Fortran and it does not need abstract types, or other such interesting Fortran, it just needs statistical skills and a good compiler and this is the best and it is free, which helps in academic research.  And this site has some of the best Fortran programmers in the world who answer actual difficult questions on Fortran that I have used to study for example, COVID Virus, actually yesterday we finished a proposal to develop methods to find the next COVID not 19, again it will be based in Fortran.

So thank you.  

[OP1]

In light of your comment, do you think that the following code is standard-compliant? It compiles and runs without any issue with the OneAPI ifort compiler:

MODULE M
IMPLICIT NONE


TYPE, ABSTRACT :: T
    CONTAINS
        PROCEDURE(T_PROC),DEFERRED :: PROC
END TYPE T
ABSTRACT INTERFACE
    SUBROUTINE T_PROC(SELF)
    IMPORT :: T
    IMPLICIT NONE
    CLASS(T) :: SELF
    END SUBROUTINE T_PROC
END INTERFACE


TYPE, EXTENDS(T) :: U
    CONTAINS
        PROCEDURE :: PROC => U_PROC
END TYPE U
INTERFACE
    MODULE SUBROUTINE U_PROC(SELF)
    IMPLICIT NONE
    CLASS(U) :: SELF
    END SUBROUTINE U_PROC
END INTERFACE


TYPE, EXTENDS(U), ABSTRACT :: V
    CONTAINS
        PROCEDURE(V_PROC),DEFERRED :: PROC
END TYPE V
ABSTRACT INTERFACE
    SUBROUTINE V_PROC(SELF)
    IMPORT :: V
    IMPLICIT NONE
    CLASS(V) :: SELF
    END SUBROUTINE V_PROC
END INTERFACE


TYPE, EXTENDS(V) :: W
    CONTAINS
        PROCEDURE :: PROC => W_PROC
END TYPE W
INTERFACE
    MODULE SUBROUTINE W_PROC(SELF)
    IMPLICIT NONE
    CLASS(W) :: SELF
    END SUBROUTINE W_PROC
END INTERFACE

CONTAINS

    MODULE SUBROUTINE U_PROC(SELF)
    IMPLICIT NONE
    CLASS(U) :: SELF
    WRITE(*, *) 'U'
    END SUBROUTINE U_PROC

    MODULE SUBROUTINE W_PROC(SELF)
    IMPLICIT NONE
    CLASS(W) :: SELF
    WRITE(*, *) 'W'
    END SUBROUTINE W_PROC

END MODULE M


PROGRAM P
USE M
IMPLICIT NONE
TYPE(W) :: MY_VAR
CALL MY_VAR%PROC
END PROGRAM P

[FortranFan · Accepted solution]

@OP1 wrote:
In light of your comment, do you think that the following code is standard-compliant? It compiles and runs without any issue with the OneAPI ifort compiler: ..

Based on my read of the standard, no the posted code does not conform.

Intel Fortran compiler is in error here, it appears to not enforce a numbered constraint in the standard, "C789 (R749) An overriding binding (7.5.7.3) shall have the DEFERRED attribute only if the binding it overrides is deferred."

[Steve_Lionel]

NAG Fortran agrees with @FortranFan here.

Error: t.f90(32): Inherited non-DEFERRED type-bound procedure PROC cannot be overridden by a DEFERRED one; detected at PROC@<end-of-statement>

[OP1]

Thanks @Steve_Lionel and @FortranFan . I will report this bug to Intel.

[Ron_Green]

I will start the bug report and watch for your issue to come in.  Consider it Bug pre-fetching.   If you prefer, I can simply take the bug report from here and save you the time with the write up.

[OP1]

Thanks @Ron_Green  - I did report it. "Bug pre-fetching", I like that, ha ha!