(j3.2006) About extending abstract types with deferred bindings

[Cohen Malcolm]

<<<
This comes up because a couple of our customers bemoaned the restriction in 
F08/0052, saying ?The result of the interp results in a capability gap for 
authors when they want a binding that can be overriden but not invoked?, 
and asked that such a capability be provided in a future standard.
>>>

The requirement to have all deferred type-bound procedures overridden in a 
non-ABSTRACT type does not come out of this interp.  It comes out of the 
basic requirement that it be impossible to invoke a deferred tbp.  If you 
want to instantiate something without overriding a tbp, simply don't make 
that tbp deferred - put in a stub that does an ERROR STOP.

It is literally impossible for a concrete object ever to have the 
capabilities of:
(a) a binding can be overridden
(b) that binding cannot be invoked
except in the case when the procedure has a nonoptional nonpointer 
nonallocatable dummy argument for which it is impossible to create any 
acceptable actual argument, e.g. by having it be of a nonsequence type 
private to the procedure.

<<<
Is there a prohibition against invoking an accessible deferred procedure 
binding using an abstract ancestor component of a non-abstract object?
>>>

In effect.  The rules prevent instantiating an object of abstract type in 
the first place.

<<<
Do we need
>>>

No.

Cheers,
-- 
........................Malcolm Cohen, Nihon NAG, Tokyo.