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

Differences between 1.2 and version 1.3
Log of other versions for file ai12s/ai12-0328-1.txt

--- ai12s/ai12-0328-1.txt	2019/04/12 04:56:28	1.2
+++ ai12s/ai12-0328-1.txt	2019/04/17 00:01:17	1.3
@@ -1,5 +1,6 @@
-!standard 4.5.2(28.1/4)                                    19-04-10  AI12-0328-1/02
+!standard 4.5.2(28.1/4)                                    19-04-16  AI12-0328-1/03
 !standard 4.5.2(4.1/4)
+!standard 4.5.2(15/3)
 !class binding interpretation 19-04-10
 !status work item 19-04-05
 !status received 19-03-28
@@ -14,7 +15,7 @@
 
 !question
 
-RM 4.5.2(28-28.1/4) (A Dynamic Semantics rule) reads:
+4.5.2(28-28.1/4) (A Dynamic Semantics rule) reads:
 
 An individual membership test yields the result True if: 
 
@@ -25,41 +26,80 @@
   equality.
 
 How does this work if the tested type is private? Does it depend on the
-view of the type? (No.)
+view of the type? (No, presuming it is legal on both views -- we make it
+illegal on the full view in some cases)
 
 !wording
 
-Modify RM 4.5.2(4.1/4):
+Modify 4.5.2(4.1/4):
 
   If a membership test includes one or more choice_simple_expressions
   and the tested type of the membership test is limited, then the tested
   type of the membership test shall have a visible primitive equality
-  operator[.]{; if the tested type of the membership test is nonlimited
-  with a limited partial view, the tested type shall be a record type or
-  the limited partial view shall not have a visible primitive equality
-  operator}.
+  operator{; if the tested type of the membership test is nonlimited
+  with a user-defined primitive equality operator that is defined at a point
+  where the type is limited, the tested type shall be a record type or
+  record extension}.
 
-    AARM Reason: We make the membership test on the full view of a type
+    AARM Reason: We make the membership test on the nonlimited view of a type
     illegal if it would use a different equality operator than what
-    would be used on its (limited) partial view.
+    would be used for a limited view of the type.
 
+Modify 4.5.2(15/3):
+
+  For a private type, if its full type is a record type {or record extension}, 
+  predefined equality is defined in terms of the primitive equals operator of 
+  the full type; otherwise, predefined equality for the private type is that 
+  of its full type.
+
+Modify 4.5.2(28.1/4):
+
+  * The membership_choice is a choice_simple_expression, and the
+    tested_simple_expression is equal to the value of the
+    membership_choice. If the tested type is a record type [or a limited
+    type]{or a record extension, or is limited at the point where the
+    membership test occurs}, the test uses the primitive equality for
+    the type; otherwise, the test uses predefined equality.
+    
+      AARM Reason: Note that if the membership test occurs where the
+      type is nonlimited, and not a record type or record extension, we
+      use the predefined equality operator, presuming the usage is legal.
+
 !discussion
+
+We want to be sure that you get the same result from a membership test
+applied to the full view and the partial view, if both are legal. 
+Similarly, if the type is limited and then at a later point it becomes
+nonlimited, we want to get the same answer.  What we do is make it
+illegal to perform a membership test on a nonlimited type if there is
+place where it is limited and has a visible primitive equality operator,
+unless that type is a record type or a record extension (since those use
+the primitive equality operator everywhere.)
+
+Making the dynamic semantics give different values depending on the view
+is frowned upon, especially for an expression that could conceivably be
+used in a default expression, where the default expression in the body
+would see the nonlimited view, while the default expression in the spec
+would see the limited view. For this special case, we make such a
+membership test illegal where the nonlimited view is in scope.  The
+membership test can easily be replaced by a use of one or more equality
+tests, in which case the same (primitive) equality operator would be
+used independent of view, so there is an easy workaround in a case where
+the membership test is made illegal by this change.
+
+In rewording 4.5.2(28.1/4), it was noticed that a record extension is not
+a record type. Thus, we have to mention both. We also have to change the
+similar wording in 4.5.2(15/3), so that a case like the following gets the
+correct result for the private view:
+
+   package P1 is
+      type Priv is tagged private;
+   private
+      type Priv is new Controlled with null record;
+   end P1;
 
-We want to be sure that you get the same result from a membership test applied
-to the full view and the partial view, if both are legal. For the case of a 
-limited partial view, the membership test is legal so long as there is a 
-primitive equality operator. But if the full view is nonlimited, and not a 
-record type, then the dynamic semantics say we use the predefined equality.
-Making the dynamic semantics view dependent is frowned upon, especially for an
-expression that could conceivably be used in a default expression, where the 
-default expression in the body would see the full view, while the default 
-expression in the spec would see the partial view.
-
-For this special case, we make such a membership test illegal when the full 
-view is in scope. The membership test can easily be replaced by a use of one 
-or more equality tests, in which case the same (primitive) equality operator 
-would be used independent of view, so there is an easy workaround in a case 
-where the membership test is made illegal by this change.
+(Note that if Priv was a private extension, then 4.5.2(14/3) would apply.)
+Again, this is necessary so that result of equality is not view-specific.
 
 !ASIS
 

Questions? Ask the ACAA Technical Agent