!standard 7.3.1(5.2/3)                              13-12-17    AI12-0065-1/02
!class ramification 13-12-17
!status Corrigendum 2014 13-12-17
!status ARG Approved 6-0-5  13-11-17
!status work item 13-05-08
!status received 13-01-26
!priority Low
!difficulty Medium
!qualifier Clarification
!subject Descendants of incomplete views

!summary

It is possible for a type T3 to be indirectly derived from a type T1 but
inherit no characteristics from T1, because one of its ancestors, say T2,
is declared at a point where the derivation from T1 is not visible.
The wording in 7.3.1 should be clarified to explain this.

!question

The example of AARM 7.3.1(5.a.1-4/3) doesn't seem to have much to do with the
paragraph 7.3.1(5.2/3) that precedes it. Moreover, that paragraph is supposed to
be redundant, but it claims that types can be descendants of incomplete views of
a type, which is not backed up by any other text in the standard.

Should this be clarified? (Yes.)

!response

Paragraph 7.3.1(5.2/3) was intended to be a clarification of 7.3.1(5.1/3), but
its wording was sufficiently confusing that it only made matters worse.  We
have tried to clarify the intent a bit.  

Also, the AARM example was similarly intended to clarify things, but the
mapping between the example and 5.2/3 was not clear, so again, things
only became further muddled. Hopefully the added comments have helped
explain how the example relates to 5.2/3.

!wording

Modify 7.3.1(5.2/3, 5.a.*/3) as follows:

   [redundant: [It]{Furthermore, it} is possible for there to be places
   where a derived type is [visibly a descendant of] {known to be
   derived indirectly from} an ancestor type, but is not a descendant of
   even a partial view of the ancestor type, because the parent of the
   derived type is not visibly a descendant of the ancestor. In this
   case, the derived type inherits no characteristics from that
   ancestor, but nevertheless is within the derivation class of the
   ancestor for the purposes of type conversion, the "covers"
   relationship, and matching against a formal derived type.  In this
   case the derived type is [considered to be] {effectively} a
   descendant of an incomplete view of the ancestor. -- end redundant]

  Discussion: Here is an example of this situation: 

    package P is
       type T is private;
       C : constant T;
    private
       type T is new Integer;
       C : constant T := 42;
    end P;

    with P;
    package Q is
        type T2 is new P.T;  {-- T2 is *not* a descendant of Integer} 
    end Q;

    with Q;
    package P.Child is
        type T3 is new Q.T2;  -- 
    private
       {--  Here T3 is known to be indirectly derived from Integer, but 
        --  inherits *no* characteristics from Integer, since T2 inherits
        --  no characteristics from Integer.
        --  However, we allow an explicit conversion of T3 to/from Integer.
        --  Hence, T3 is effectively a descendant of an "incomplete" view of
        --  Integer.}
        Int : Integer := 52;
        V : T3 := T3(P.C);  -- Legal: conversion allowed
        W : T3 := T3(Int);  -- Legal: conversion allowed
        X : T3 := T3(42);   -- Error: T3 is not a numeric type
        Y : T3 := X + 1;    -- Error: no visible "+" operator
        Z : T3 := T3(Integer(W) + 1);   -- Legal: convert to Integer first
    end P.Child;
    
!discussion

None needed.

!corrigendum 7.3.1(5.2/3)

@drepl
It is possible for there to be places where a derived
type is visibly a descendant of an ancestor type, but not a
descendant of even a partial view of the ancestor type, because the parent
of the derived type is not visibly a descendant of the ancestor.  In
this case, the derived type inherits no characteristics from that
ancestor, but nevertheless is within the derivation class of the
ancestor for the purposes of type conversion, the "covers"
relationship, and matching against a formal derived type. In this
case the derived type is considered to be a @i<descendant> of an
incomplete view of the ancestor.
@dby
Furthermore, it is possible for there to be places where a derived type is
known to be derived indirectly from an ancestor type, but is not a descendant
of even a partial view of the ancestor type, because the parent of the
derived type is not visibly a descendant of the ancestor. In this
case, the derived type inherits no characteristics from that
ancestor, but nevertheless is within the derivation class of the
ancestor for the purposes of type conversion, the "covers" relationship, and
matching against a formal derived type.  In this case the derived type is
effectively a @i<descendant> of an incomplete view of the ancestor.

!ACATS Test

No additional ACATS test needed.

!ASIS

No ASIS effect expected.

!appendix

From: Tucker Taft
Sent: Saturday, January 26, 2013  5:51 PM

A question came up which related to the example given in paras 5.a.1 .. 5.a.4 in
section 7.3.1.  After investigating it further, the confusion seems to be in
part related to the fact that these AARM paragraphs really relate to RM
paragraph 5.1/3, but they actually follow 5.2/3.  I'm not sure whether that is a
limitation in the tools, or just a bug.  In any case it is confusing, and if the
AARM paragraphs can't be moved, they should probably specify that they are an
example of the issue described by 5.1, rather than 5.2.

****************************************************************

From: Randy Brukardt
Sent: Saturday, January 26, 2013  7:23 PM

No tools limitation here, I put that example where the AI (AI05-0115-1)
specified that it get placed. The original AI author put that note there, in
version /08. And who was that author that specified such an apparently confusing
location? None other than S. Tucker Taft. :-) (That STT guy also revised this AI
twice more without moving this note, I had to assume its location was intended.)

There is no problem moving these paragraphs, I'll just do it silently (no
numbering changes are needed or will happen, and no text is changed) and put
this discussion into AI12-0005-1, the holder for all changes to the AARM.

****************************************************************

From: Randy Brukardt
Sent: Saturday, January 26, 2013  7:36 PM

Having looked at this more, I don't see the problem. I think STT version 1.0 was
correct in the placement of these paragraphs.

7.3.1(5.2/3) is a "redundant" clarification and amplification of 7.3.1(5.1/3),
and the examples of 7.3.1(5.a.1-4/3) appear to me to be the motivating example
for that clarification. Specifically, this example is illustrating "It is
possible for there to be places where a derived type is visibly a descendant of
an ancestor type, but not a descendant of even a partial view of the ancestor
type, because the parent of the derived type is not visibly a descendant of the
ancestor." The type T3 in this example is such a type, and the consequences that
it is legal to convert T3 to Integer, but T3 is not a numeric type (so no
literals or arithmetic).

My understanding of the intent was that everything in 7.3.1(5.2/3) follows from
7.3.1(5.1/3), but the example is supposed to be illustrating 7.3.1(5.2/3). To
the extent that it doesn't do so is probably the fault of STT version 1.0 -- who
apparently has confused STT version 2.0. (I'm not sure where an "incomplete
view" comes into this example, or any other for that matter. The text claims to
be redundant, so that should follow from other rules.)

Does any of the this make sense? (This whole descendant business is right on the
edge of insanity, so I might have gotten it wrong...) I would hope that STT
version 1.0 could be summoned to answer such questions, but that's probably
asking a lot. ;-)

****************************************************************

From: Tucker Taft
Sent: Sunday, January 27, 2013  8:37 AM

> ... Does any of the this make sense? (This whole descendant business
> is right on the edge of insanity, so I might have gotten it wrong...)
> I would hope that STT version 1.0 could be summoned to answer such
> questions, but that's probably asking a lot. ;-)

I guess either STT version 1.0 or STT version 2.0 needs to take credit for all
of this confusion, then.  Mea culpa.  The "incomplete view" comment is
particularly confusing for the current version of STT ...

Before we change anything here, we should probably discuss it at an ARG meeting
and decide how it might be better explained.

Thanks for delving into the history on this one!

****************************************************************

From: Randy Brukardt
Sent: Friday, April 12, 2013  10:54 PM

I was updating the test objective document for the aggregate clauses to include
all of the current rules, and I think I stumbled upon why this text is talking
about "incomplete views".

The rule 4.3.1(14) requires that the type of an aggregate be descended from a
record type through one of more record extensions. 4.3.1(5/3) is a similar rule
for extension aggregates. We want those rules to fail for cases like the one in
the example. Therefore, STT version 1.0 described that the hidden ancestor acts
like an incomplete view in this case -- which is not a record type or record
extension.

Unfortunately, this comes up in text that's supposedly redundant, and there
isn't a breath of anything about incomplete views anywhere in the normative
wording. And he failed to explain this reason in the associated AARM note.
Probably the text should say something like " In this case the derived type acts
like it is a descendant of an incomplete view of the ancestor." - the problem
being that the "considered to be" seems to suggest that that is the formal
effect as opposed to an informal way to think of the situation.

Of course, if this is an informal view, it then isn't obvious as to why this
triggers the 4.3.1(14) and 4.3.2(5/3) rules. (And it has to be informal if it is
redundant.) But it must trigger those rules -- we don't want to allow an
aggregate whose components aren't known -- that was the whole point of the AI
(being the original question).

So, probably a bit more wordsmithing is needed for 7.3.1(5.1-2/3). Hopefully STT
version 2.0 can figure it out.

****************************************************************

From: Randy Brukardt
Sent: Friday, April 12, 2013  11:30 PM

Another issue that strikes me with the wording of 7.3.1(5.2/3) is that it talks
about the "parent of the ancestor not being visibly  inherited from the
ancestor". But that's only part of the issue: we want to trigger 4.3.1(14) and
4.3.2(5/3) in any case where there are potentially components that are not
inherited from an ancestor. That can happen in cases (like the ones in the
question of AI05-0115-1) even when the derived ancestor is known; the problem is
that ancestor is a private view.

We need to use 4.3.1(14) and 4.3.2(5/3) to make these aggregates illegal because
we don't have any rules requiring components to be visible in aggregates. We
didn't want to have such rules because that would make legality depend on the
contents of the private part (if the full type is a null record, then there
aren't any hidden components in the aggregate, but we still don't want to allow
it).

In reading the normative wording in 7.3.1(5.1/3), it appears that this has the
correct effect. So the paragraph 7.3.1(5.2/3) appears to be more misleading than
illuminating.

It's worse because the AARM example doesn't illustrate the situation of that
paragraph very well: in this example, all of the ancestors are visible, but
there are characteristics that aren't visible because some of the ancestors are
partial views (via visibility). I think Tucker meant the "ancestor" that he was
thinking of in this example to be Root_Integer, but as this is implicit its
confusing to think about that, especially without it being mentioned anywhere.
(That's why he concentrates on numeric operations in the example, but it's just
as easy to think of that as a characteristic, the "ancestorness" only really
matters for literals.)

I think the AARM example needs to actually illustrate how a ancestor could be
invisible, without the crutch of Root_Integer. I can't actually make that work,
so I'd like to see such an example (maybe it needs more levels). That's
important, because if it can't be written, then I have to think that
7.3.1(5.2/3) is doing more harm than good, and an expanded AARM note would be
preferable. The text of 7.3.1(5.1/3) explains what happens with characteristics
well enough.

I hope this clarifies and does not confuse further!

****************************************************************

From: Tucker Taft
Sent: Saturday, November 16, 2013  11:31 PM

Here is an attempt to clarify 7.3.1 a bit with regard to inheriting from a type
while inheriting none of the characteristics of the type.

[This is version /01 of the AI - Editor.]

****************************************************************