Janus Weil wrote:
Thus, the only place where the check can be is for:
f => ff
In your example, the explicit interface of "ff" is known thus it should be
testable at resolution time of the proc-pointer assignment.
Right. However, strictly speaking, the pointer assignment as such is
probably valid. But of course there is not much one can do with the
proc-ptr afterwards, if it's invalid to call it ...
Well, if one doesn't want to error on it, one can still warn. However,
the following states that it is invalid:
"If the characteristics of the pointer object or the pointer target are
such that an explicit interface is required, both the pointer object and
the pointer target shall have an explicit interface." (F2008, para 4 of
"7.2.2.4 Procedure pointer assignment")
Side note: gfortran currently also accepts:
external :: qq
procedure(ff), pointer :: f => qq
where "ff" has a polymorphic argument.
Another problem is with external procedures, i.e. changing the
proc-ptr definition to a simple PROCEDURE statement (without POINTER).
There one does not have the assignment to check.
Well, we can only bark at the user, when either the procedure pointer or
its target has an explicit interface (which uses something which
requires an explicit interface). If both are not used, the user is at
his own.
However, I assume that in the most common case, the user either forgot
to add an interface to the proc-pointer (as in the PR) or mistyped the
name of the procedure (which would give a linker error) or forgot to
include a module (ditto). In modern code - and proc-pointer and CLASS
code is modern - explicit interfaces are usually available. And for
same-file procedures, we can even sneak at the gsym which catches those
as well.
Thus, while not catching all issues, it will catch a bunch of bugs (and
I think even the more common ones). Thus, we should implement the check
at some point.
Tobias
