CVS difference for ai05s/ai05-0115-1.txt

--- ai05s/ai05-0115-1.txt	2011/04/01 06:38:28	1.11
+++ ai05s/ai05-0115-1.txt	2011/04/02 07:30:35	1.12
@@ -2497,3 +2497,113 @@
 about. Could you show an example??
 
 ****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Friday, April  1, 2011  2:28 AM
+
+> However, when it comes to things like type conversion, generic 
+> instantiation as an actual for a formal derived type, "coverage" by a 
+> class-wide type, etc., I could imagine having a more flexible rule. 
+> That is, if a type knows it is derived indirectly from some type, even 
+> though its parent type does *not* know that fact, it can at a minimum 
+> be convertible to that "secret" ancestor.
+
+But then, you could access the secret components after converting to the
+secret ancestor (just a note, I don't know whether it's good or bad)
+
+> I didn't write the wording that way, but we might want to consider it. 
+> One way I imagined doing that was saying that in cases like that, the 
+> child type is essentially a descendant of an "incomplete" view of the 
+> ancestor.
+> It inherits no characteristics from that ancestor, other than the 
+> right to be converted to it, or to match it for the purposes of formal 
+> derived types, or things like that ('Class coverage, etc.).
+> I have some suspicion that this approach would be more compatible with 
+> what most compilers do today, and it doesn't seem to cause any 
+> trouble. This is in contrast to inheriting characteristics from such a 
+> secret ancestor, as you could get into real trouble if you could see a 
+> component of a secret ancestor that had the same name as a component 
+> of your parent type (unbeknownst to the parent type).
+
+And after conversion, there is no ambiguity since new homonym components
+have been stripped off. Might be a good thing after all.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, April  1, 2011  10:49 AM
+
+> Humm, I don't seem to have managed to create the situation you are 
+> worried about. Could you show an example??
+
+Something like this:
+
+     with P1.P2;
+     package P5 is
+         type SubSub is new SubRoot with ...
+     end P5;
+
+     package P1.P2.P6 is
+         type Sub3 is new SubSub with ...
+
+     private
+         X : Root'Class := Sub3'(...);  -- Legal?
+            -- We can "see" that SubRoot is derived from Root
+            -- but our Parent SubSub cannot.
+     end P1.P2.P6;
+
+I don't know that I am "worried" about this in the abstract, but I am concerned
+if there is a chunk of existing code that will break due to such a "refinement"
+of the definition.
+
+Ed reported that he didn't see any significant problems in the AdaCore regression
+test suite, but that may have only been with the instantiation situation where
+an actual type was a "secret" descendant of the formal derived type ancestor.
+
+In any case I think we definitely want to say that as far as inheriting subprograms,
+components, ability to write aggregates, etc., we stick with the "refined" model.
+The only open question in my mind is this issue of conversion/matching, as it
+seems like a useful work-around for a programmer in certain situations where the
+inheritance chain is "interrupted."
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, April  1, 2011  11:28 PM
+
+>          X : Root'Class := Sub3'(...);  -- Legal?
+>             -- We can "see" that SubRoot is derived from Root
+>             -- but our Parent SubSub cannot.
+>      end P1.P2.P6;
+
+I see. I don't think we ever do this in Claw, so now I'm less worried.
+
+> I don't know that I am "worried" about this in the abstract, but I am 
+> concerned if there is a chunk of existing code that will break due to 
+> such a "refinement" of the definition.
+
+Right.
+
+> Ed reported that he didn't see any significant problems in the AdaCore 
+> regression test suite, but that may have only been with the 
+> instantiation situation where an actual type was a "secret" descendant 
+> of the formal derived type ancestor.
+> 
+> In any case I think we definitely want to say that as far as 
+> inheriting subprograms, components, ability to write aggregates, etc., 
+> we stick with the "refined" model.  The only open question in my mind 
+> is this issue of conversion/matching, as it seems like a useful 
+> work-around for a programmer in certain situations where the 
+> inheritance chain is "interrupted."
+
+Right. It seems nasty to say that you can't convert to a type that you can see.
+
+But I suppose you can work around it in multiple steps:
+
+          X : Root'Class :=
+             Root'Class(SubRoot'Class(Sub3'(...)));
+
+I know I did this occasionally in the Claw builder code, but I think it was
+caused by more straightforward "invisibilities".
+
+****************************************************************