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

[Van Snyder]

On Fri, 2016-09-09 at 10:47 +0900, Cohen Malcolm wrote:
> If one rashly imagines that we got some of this stuff right, a simple
> search for "abstract type" turns up several obvious constraints. 

I had rashly assumed we got this right, so I looked for a relevant
constraint in Clause 15, not Clause 9.

Constraint C911 exists, but it's in the wrong place.  It's a too-big
hammer.  It prevents too much.  In particular, it prevents accessing the
parent component of an object of an extension type of an abstract type,
as a whole data object.  The parent component is a perfectly good
object.  The only problem with objects of abstract type is invoking
deferred procedure bindings, which we could have successfully
accomplished without preventing data access if we had gotten this right.
C911 could instead be C1535a, mutatis mutandis:

C1535a (R1523) If the rightmost <part-name> of <data-ref> is of abstract
       type, <data-ref> shall be polymorphic.

This indirectly prevents trying to invoke a deferred procedure binding
using an object of abstract type, even using the parent component of an
object of an extension type of an abstract type (because the parent
component isn't polymorphic), but it doesn't prevent accessing the
object as a data object.

This is still indirect, and a too-big hammer, because it also prevents
invoking bindings that aren't deferred (which is what it ought to
address directly instead of indirectly), so an even better (i.e., more
precise) constraint would be:

C1535a (R1523) If the rightmost <part-name> of <data-ref> is of abstract
       type and <data-ref> is not polymorphic, the <binding-name> shall not
       have the DEFERRED <binding-attr>.

This is a bit too wordy (and so is C911), in light of 9.4.2p4:

        "The type and type parameters, if any, of a <data-ref> are those
        of the rightmost part name."

We also don't need to mention abstract type, since a nonabstract type
doesn't have deferred bindings.  So even better would be:

C1535a (R1523) If <data-ref> is not polymorphic, the <binding-name>
       shall not have the DEFERRED <binding-attr>.

This only prevents trying to invoke deferred procedure bindings, which
is all we really need to accomplish.  It doesn't prevent invoking
non-deferred bindings using the parent component of an object of an
extension type of an abstract type, which would occassionally be useful,
and it doesn't prevent accessing the parent component as a data object.

So, my rash assumption was wrong.  We didn't get this right.  I assume
we can't repair this blunder now.