Version 1.4 of ai12s/ai12-0065-1.txt

Unformatted version of ai12s/ai12-0065-1.txt version 1.4
Other versions for file ai12s/ai12-0065-1.txt

!standard 7.3.1(5.2/3)          13-11-16 AI12-0065-1/01
!class binding interpretation 13-05-08
!status work item 13-05-08
!status received 13-01-26
!priority Low
!difficulty Medium
!qualifier Omission
!subject Descendants of incomplete views
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.
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.)
(See !summary.)
** TBD. 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;
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.
No additional ACATS test needed.
No ASIS effect expected.

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

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

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

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.]


Questions? Ask the ACAA Technical Agent