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

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

--- ai12s/ai12-0328-1.txt	2019/04/06 03:55:09	1.1
+++ ai12s/ai12-0328-1.txt	2019/04/12 04:56:28	1.2
@@ -1,5 +1,6 @@
-!standard 4.5.2(28.1/4)                                    19-04-05  AI12-0328-1/01
-!class ramification 19-04-05
+!standard 4.5.2(28.1/4)                                    19-04-10  AI12-0328-1/02
+!standard 4.5.2(4.1/4)
+!class binding interpretation 19-04-10
 !status work item 19-04-05
 !status received 19-03-28
 !priority Low
@@ -7,8 +8,9 @@
 !subject Meaning of limited type and record type in 4.5.2(28.1/4)
 !summary
 
-The view of the type is irrelevant when determining whether a type is a
-record type or a limited type for the purposes of 4.5.2(28.1/4).
+Membership test on a type with a limited partial view with a 
+user-defined primitive "=" is illegal in the scope of the full type,
+if the full type is nonlimited.
 
 !question
 
@@ -25,97 +27,39 @@
 How does this work if the tested type is private? Does it depend on the
 view of the type? (No.)
 
-!response
+!wording
 
-AARM 3.1(7-7.d/3) discuss the definition of "view of an entity", and when 
-"view of" is implied. In particular, AARM 3.1(7.d/3) says:
+Modify RM 4.5.2(4.1/4):
 
-   On the other hand, run-time rules can work either way, 
-   so "view of" should not be assumed in Dynamic Semantics rules.
+  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}.
+
+    AARM Reason: We make the membership test on the full view of a type
+    illegal if it would use a different equality operator than what
+    would be used on its (limited) partial view.
 
-The rules discussed above are Dynamic Semantics rules, and "view of" does not
-appear. Moreover, it is usual that privacy is ignored for runtime rules, so
-this is not that unusual.
-
-Therefore, private types are ignored when determining whether a type is a
-record type or a limited type for the purposes of determining the execution
-of a membership test.
-
 !discussion
-
-The basic idea is that a membership test works the same way as composition
-of equality, and predefined equality for a generic formal private type.
-
-Thus, if we have:
-
-   package P1 is
-      type P is private;
-
-      function "=" (Left, Right : P) return Boolean;
-
-   private
-      type P is record ...
-   end P1;
-
-All three of those contexts will use the user-defined equality rather than the
-(overridden) predefined equality for type P. (Recall that Ada 2012 eliminated
-the distinction between tagged and untagged types on this point.)
-
-In particular, a membership test for type P will use the user-defined 
-equality. 
-
-Similarly, if one has an array type:
-
-   package P2 is
-      type A is array (...) of ...;
-
-      function "=" (Left, Right : A) return Boolean;
-   end P2;
-
-The predefined equality is used to compose "=" and in generic units, and 
-memberships do the same thing.
-
-The concept of a limited type is more tied up with views (there isn't a 
-private record type, but there is a limited private type). Consider for 
-instance:
-
-   package P3 is
-      type LP is limited private;
-
-      function "=" (Left, Right : LP) return Boolean;
-
-   private
-      type LP is access ...
-   end P3;
-
-In this case, the full type elementary and nonlimited. The rule tells us that
-the predefined equality is used by a membership (outside of P3) in this case, 
-even through a membership would be illegal if there was not an explicit 
-definition for "=".
-
-This admittedly is odd. Moreover, we don't have the composition (a type with
-a limited component is limited, and limited types don't have a predefined "=")
-nor generic formal private (a formal limited private type does not import
-"=") to guide us. We could talk about the re-emergence in a nested type, but
-the "=" can only be used in the body of P3 (and of its children), and the case
-is argubly a pathology.
-
-We could consider using a view-based rule for cases like these. However, they
-lead to oddities where a membership on LP gets a different result in the body
-of P3 (where the full type for LP is visible) than in the specification and
-clients. This could be problematical for default expressions, where the value
-could depend on where it is evaluated, even if all of the denoted objects are
-the same.
-
-[This concern comes to us courtesy of Steve Baird, who else? He and I disagree
-how a view-specific Dynamic Semantics rule would be applied in this case, and
-it probably is better to avoid the question in the first place. - Editor.]
 
-[Author's aside: For the record, GNAT 18.1 gets all of this wrong. But it uses
-predefined equality for all memberships, including for types that are immutably
-limited and have no equality at all, rather than rejecting them. So I don't 
-think this was a thought-out implementation, but rather just whatever fell 
-out.] 
+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.
 
 !ASIS
 

Questions? Ask the ACAA Technical Agent