CVS difference for ai22s/ai22-0005-1.txt

--- ai22s/ai22-0005-1.txt	2021/11/09 06:46:18	1.1
+++ ai22s/ai22-0005-1.txt	2021/11/13 07:58:42	1.2
@@ -34,3 +34,171 @@
 
 ****************************************************************
 
+From: Steve Baird [privately]
+Sent: Tuesday, August 24, 2021  7:20 PM
+
+We have the inheritance rule in 13.1(15.5):
+   if the name denotes one or more primitive subprograms of the type, the
+   inherited aspect is a name that denotes the corresponding primitive
+   subprogram(s) of the derived type;
+
+For tagged types, I think the meaning  of the above rule is clear, at least in
+the context of inherited Integer_Literal, Real_Literal, and String_Literal
+aspects (because for those we don't care about things like formal parameter
+names and default expressions). If a primitive subprogram for a tagged type
+has more than one view floating around, we don't care much about which one
+we get. See, for example, the words "[even if the declaration occurs in
+a private part]" in 3.9.2(20.1).
+
+But let's look at an untagged example with an overriding function declared
+in the private part of the enclosing package:
+
+  procedure Foo is
+    pragma Assertion_Policy (Check);
+
+    package Pkg1 is
+       type Parent_Type is record X, Y : Integer; end record
+            with Integer_Literal => I_L;
+       function I_L (S : String) return Parent_Type is (0, 0);
+    end Pkg1;
+
+    package Pkg2 is
+       type Descendant is new Pkg1.Parent_Type;
+    private
+       overriding function I_L (S : String) return Descendant is (1, 1);
+    end Pkg2;
+
+    package Client is
+          D : Pkg2.Descendant := 123;
+    end Client;
+begin 
+    pragma Assert (Client.D = ???);
+end Foo;
+
+What value should be assigned to Client.D?
+4.2.1(7) says that evaluating the literal 123 is "is equivalent to a call to 
+the subprogram denoted by the corresponding aspect of T".
+And that takes us to 13.1(15.5) and the word "corresponding".
+
+It seems desirable to me that if an integer literal can be interpreted as an
+expression of a non-numeric type, then all integer literals of that type ought
+to generate calls to the same subprogram, regardless of where each literal
+occurs.
+
+FWIW, the phrase "corresponding primitive" occurs on 11 different RM pages.
+Hopefully they have consistent meanings.
+
+What do you think?
+
+****************************************************************
+
+From: Randy Brukardt [privately]
+Sent: Wednesday, August 25, 2021  9:59 PM
+
+[Editor's note: I removed the bulk of this private thread, which had many
+false starts and confusions. I've just left parts relevant to the conclusion.]
+
+[Tuck replied in part: "Yes, I agree we want to call the overriding function, 
+even if it is not visible. So some wording should be provided to clarify that."]
+ 
+That would be wildly incompatible (assuming you are speaking generally, which 
+is how I interpreted this). Overriding of untagged operations is purely a
+visibility thing, hiding the inherited version. It doesn't have an effect on
+calls.
+ 
+I suppose we could have nonoverridable aspects work differently than other 
+untagged overridding, but that would be extremely strange. If we really want 
+to do that, we probably should decouple that from overriding, since they would 
+work completely differently. (And I agree how stream attributes work, but they 
+don't have anything to do with overriding, presumably for this reason).
+ 
+...
+
+****************************************************************
+
+From: Tucker Taft [privately]
+Sent: Wednesday, August 25, 2021  8:29 AM
+
+> That would be wildly incompatible (assuming you are speaking generally,
+> which is how I interpreted this). Overriding of untagged operations is 
+> purely a visibility thing, hiding the inherited version. It doesn't have
+> an effect on calls.
+
+I was not talking generally, but was rather suggesting this should be a 
+special case for non-overridable aspects, but I have changed my mind.  In 
+general when you specify an aspect, it must be resolved before the end of the
+immediately enclosing declaration list, so anything that happens after that 
+should be irrelevant for an untagged type.  So I now say it should return 
+(0,0) whether or not you can see the private overriding.  Hopefully compilers
+will give a warning if you override a primitive of an untagged type in the 
+private part, as that is generally a misleading thing to do.  
+
+In any case we need to clarify what happens in this case.  I would say the 
+inherited aspect needs to be resolved within the same declaration list as the
+derived type declaration, and once resolved, it is "sticky" and is not
+affected by a subsequent overriding of the operation.
+ 
+> I suppose we could have nonoverridable aspects work differently than other 
+> untagged overridding, but that would be extremely strange. If we really want
+> to do that, we probably should decouple that from overriding, since they
+> would work completely differently. (And I agree how stream attributes work,
+> but they don't have anything to do with overriding, presumably for this
+> reason).
+
+I am now in agreement with you that nonoverridable aspects of untagged types 
+should work the same as calls on a primitive of a untagged type, which means 
+overriding in a private part is almost always a mistake.
+ 
+...
+
+****************************************************************
+
+From: Steve Baird [privately]
+Sent: Wednesday, August 25, 2021  2:16 PM
+
+Would an AARM note (and no other change) be appropriate?
+
+Perhaps immediately after 13.1(15.5):
+   AARM Note: A subprogram declared after the end of the enclosing 
+   declaration list of the derived type (in particular, in the private
+   part of a package if the derived type is declared in the package's
+   visible part) is never considered to be "corresponding" with respect
+   to this rule.
+
+****************************************************************
+
+From: Tucker Taft [privately]
+Sent: Wednesday, August 25, 2021  4:01 PM
+
+[Editor's note: After several rounds of wordsmithing, removed here.]
+
+I knew you would have exactly this objection... ;-)  I told the truth, but 
+not the whole truth!  I thought that was OK in a note, but the whole-truth 
+police caught me.  So perhaps:
+
+AARM Note: A primitive subprogram that is declared after the end of the 
+enclosing declaration list of a derived type (in particular, in the private
+part of a package if the derived type is declared in the package's visible 
+part) is not the "corresponding primitive subprogram" in the sense of this 
+rule.  In a case like this, the corresponding primitive subprogram is 
+actually the inherited subprogram.  This doesn't make a difference for 
+tagged types, because of the "dispatching" semantics used, which means a 
+call on the inherited subprogram actually "reaches" the body of the 
+overriding.  But for untagged types, overriding an inherited subprogram of
+an untagged derived type in the private part is "too late" to have an effect
+on external uses of the primitive, since non-visible overridings are not 
+generally reachable, and a call that only "sees" the inherited subprogram
+goes to the body of the parent's operation, effectively ignoring the
+private overriding.  This same rule applies to aspects that denote an 
+inherited subprogram of an untagged derived type -- the private overriding
+is effectively ignored.
+
+****************************************************************
+
+From: Jeff Cousins [privately]
+Sent: Tuesday, November 9, 2021  3:16 AM
+
+4.3.3(15.2/5) The AI given in the AARM is wrong, it should be AI12-0236-1 
+not AI05-0147-1.
+
+****************************************************************