>> It is nontrivial to detect this in every case (e.g. passing a TYPE >> actual to a CLASS formal arg), but at least we can easily detect it if >> a polymorphic *actual* argument is involved (which means that the >> corresponding formal arg must also be polymorphic). > > > Sorry, I cannot follow here. At least at a glance, I don't see why the > following program is invalid: > > implicit none > type :: nc > end type > class (nc), allocatable :: c > procedure(), pointer :: f => ff > allocate(c) > call f(c) > contains > subroutine ff (self) > TYPE(nc) :: self > end subroutine > end > > > I don't see a reason why an explicit interface should be required - and > passing a CLASS to a TYPE is also fine: "The dummy argument shall be type > compatible with the actual argument. If the actual argument is a polymorphic > coindexed object, the dummy argument shall not be polymorphic."
I guess you're right. Somehow I was assuming that passing CLASS to TYPE is invalid (apparently without properly thinking it through). Of course this makes the diagnosis make harder ... > 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 ... 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. I'm a bit puzzled about what to do with this PR now ... Cheers, Janus
