CVS difference for ai12s/ai12-0005-1.txt

--- ai12s/ai12-0005-1.txt	2019/11/15 05:18:40	1.32
+++ ai12s/ai12-0005-1.txt	2020/01/14 05:15:42	1.33
@@ -1780,7 +1780,178 @@
 
 ***************************************************************
 
-Editor's note (November 14, 2019): All of the items above this
+From: Steve Baird
+Sent: Saturday, November 23, 2019  1:22 PM
+
+In some cases involving general access types and tagged types (thanks to
+Randy for pointing out the latter case), evaluation of a membership test
+    X in S
+includes both
+    a) determining whether the value of X is convertible to the type
+       (as opposed to the subtype) of S
+and
+    b) having converted the value of S to the type of S, determining
+       whether that converted value satisfies the subtype-specific
+       requirements of S - constraints, null exclusions, and predicates.
+
+At least that is how it should be defined. In particular, performing the
+second step makes no sense if the outcome of the first step is
+"no, this value is not convertible to the target basetype". So we
+want some short-circuiting here.
+
+Unfortunately, that is not what the current wording in RM 4.5.2 says.
+
+I see two separate questions here:
+    1) Strictly speaking, is the current wording broken? IMO, it is.
+    2) If there is a problem, what (if anything) should be done about it?
+    Would an AARM note suffice, or do we need normative RM wording, or
+    something in between (e.g., a TBH note in the RM)?
+
+Consider the following example:
+
+    procedure P1 is
+       -- The reader can decide whether "P" is short for "Procedure"
+       -- or "Pathology".
+
+       pragma Assertion_Policy (Check);
+
+       type T1 is record
+          Data : Integer := 0;
+          Predicate_Test_Count : Natural := 0;
+       end record;
+
+       type T1_Ref is access all T1;
+
+       Const : aliased constant T1 := (123, 0);
+       Ref : access constant T1 := Const'Access;
+
+       function Odd_Predicate (X : T1_Ref) return Boolean is
+       begin
+           X.Predicate_Test_Count := @ + 1;
+           return X.Data mod 2 /= 0;
+       end Odd_Predicate;
+
+       subtype S1 is T1_Ref with Dynamic_Predicate =>
+         Odd_Predicate (S1);
+    begin
+       if Ref in S1 then
+          raise Program_Error;
+       end if;
+    end P1;
+
+We don't want to see Odd_Predicate being invoked with
+an access-to-constant value, but the current RM wording
+seems to allow this possibility.
+
+Randy points out that similar scenarios are possible
+involving something like
+
+    type Root is tagged null record;
+    type Ext is new root with Data : Integer; end record;
+    function Is_Even (Param : Ext) return Boolean is
+       (Param.Data mod 2 = 0);
+    subtype Even_Ext is Ext
+      with Dynamic_Predicate => Is_Even (Even_Ext);
+
+    function F (X : Root'Class) return Boolean is
+       (X in Even_Ext);
+
+    Flag : Boolean := F (Root'(null record));
+
+where we don't want to see the function Is_Even being invoked
+with an argument that doesn't even have a Data component.
+
+My guess (and this is only a guess) is that clarifying the point
+that we don't perform subtype-specific portions of a membership
+test until after ascertaining that the basetype conversion would
+succeed would have no impact on most compilers; this is probably
+what they are doing already. This is just a matter of making
+the RM wording match what was "obviously" intended.
+
+***************************************************************
+
+From: Tucker Taft
+Sent: Sunday, November 24, 2019  9:39 AM
+
+I would say an AARM "to-be-honest" note would be adequate.  I presume in the 
+long run we would think about ways to incorporate the various TBH notes 
+directly into the normative text, but in cases like this, it seems better to 
+avoid reworking the normative wording (but I could be convinced otherwise!).
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Sunday, November 24, 2019   6:14 PM
+
+I agree. I doubt any implementer is likely to make a mistake here, mainly 
+because evaluating a predicate is in general more expensive than checking a 
+tag (and certainly more expensive than compile-time checks). So simply having 
+a note so that anyone that wonders is aware that the order might matter seems 
+like enough.
+
+***************************************************************
+
+From: Steve Baird
+Sent: Monday, November 25, 2019  12:16 PM
+
+Sounds good to me.
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Monday, November 25, 2019   2:43 PM
+
+Do you want a separate AI, or is it OK to just file this thread into
+AI12-0005-1 (the "fixes for the AARM" AI, which is an empty AI that just holds 
+AARM fixes for the record - never to be voted on by the ARG)?
+
+***************************************************************
+
+From: Steve Baird
+Sent: Monday, November 25, 2019   6:26 PM
+
+Fine with me if we make adding this TBH note an editorial fix (i.e., the 
+AI12-0005-1 alternative).
+
+If anyone wants to discuss this, speak up and we'll turn it into its own AI.
+
+***************************************************************
+
+From: Pat Rogers
+Sent: Wednesday, December 4, 2019  12:13 PM
+
+In 6.1.1, para 27.j/3, we have a paragraph starting with
+
+"In this example, the compiler cannot know the value of I when the subprogram 
+returns (since the subprogram execution can change it),"
+
+that ends with
+
+"which eliminates anything that could change at during execution."
+
+
+So the word "at" is extraneous.
+
+It may be removed already in the latest copy but I suspect not.
+
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Friday, December 6, 2019  10:32 PM
+
+This appears in the Ada 2012 version of the AARM, so it's not on anyone's 
+radar for fixing. I'll put this into the "Comments on the AARM" AI 
+(AI12-0005-1), which is just a mail collection. The error is fixed in the 
+working copy of the AARM.
+
+***************************************************************
+
+
+
+
+
+Editor's note (January 10, 2020): All of the items above this
 marker have been included in the working version of the AARM.
 
 ****************************************************************