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

--- ai22s/ai22-0005-1.txt	2022/02/04 03:54:52	1.4
+++ ai22s/ai22-0005-1.txt	2022/09/03 05:35:45	1.5
@@ -83,171 +83,11 @@
 
 ****************************************************************
 
-From: Steve Baird [privately]
-Sent: Tuesday, August 24, 2021  7:20 PM
+From: Randy Brukardt
+In part from issue #19 - September 2, 2022
 
-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;
+The profiles defined all should be indexed like "profiles, Ravenscar"
+(similarly to restrictions).
 
-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.
-
-****************************************************************