CVS difference for ai05s/ai05-0153-3.txt

Differences between 1.7 and version 1.8
Log of other versions for file ai05s/ai05-0153-3.txt

--- ai05s/ai05-0153-3.txt	2011/02/11 04:48:24	1.7
+++ ai05s/ai05-0153-3.txt	2011/02/11 04:57:17	1.8
@@ -1,4 +1,4 @@
-!standard  3.2.4(0)                                11-02-08    AI05-0153-3/03
+!standard  3.2.4(0)                                11-02-10    AI05-0153-3/04
 !class Amendment 09-05-27
 !status work item 09-05-27
 !status received 09-05-27
@@ -99,6 +99,8 @@
 Letter is also allowed in a 'for' loop, but nonstatic cases
 are not.
 
+Note that case_expression and if_expression are defined in AI05-0188-1.
+
 !wording
 
 This AI depends on AI05-0183-1, which defines the syntax for
@@ -166,9 +168,10 @@
 
     - a static expression that does not raise any exception;
 
-    - a membership test whose simple_expression is the current instance, and
-      whose membership_choice_list obeys the rules for a static membership test
-      given in 4.9;
+    - a membership test whose simple_expression is the current instance,
+      or a case_expression whose *selecting_*expression is the current instance,
+      if this expression would be static if the current instance
+      were replaced with a static expression;
 
     - a call to a predefined equality or ordering operator, where one operand
       is the current instance, and the other is a static expression;
@@ -211,19 +214,24 @@
 
 If any of the above Legality Rules is violated in an instance of a generic
 unit, Program_Error is raised.
-AARM Note: This is usual way around the contract model.
+In addition to the places where Legality Rules normally apply (see
+12.3), this rule applies also in the private part of an instance of a generic
+unit.
+
+AARM Note: This is usual way around the contract model. The "In addition..."
+wording is included for consistency with similar rules, even though it's
+not really necessary, since Program_Error will be raised anyway.
 
 
                           Implementation Permissions
 
-A Static_Predicate check may be omitted if the subtype with the predicate
-statically matches the nominal subtype of the value being checked.
+When the Dynamic Semantics calls for a check of a value against a
+Static_Predicate, the check may be omitted if every value that obeys the
+Static_Predicates of the nominal subtype of the value also obeys the
+Static_Predicate being checked against.
 
-AARM Reason: Well-behaved predicates should not have side effects that matter,
-so omitting the check is pretty harmless. It is possible to write
-non-well-behaved predicates, which is why the permission is needed. If the
-implementation does omit a predicate check, it cannot later assume that the
-predicate was True.
+AARM Reason: If the implementation does omit a predicate check, it cannot later
+assume that the predicate was True, unless that can be proven.
 
 
 NOTE: A predicate clause does not cause a subtype to be considered
@@ -312,16 +320,27 @@
 
   A constraint is statically compatible with a scalar subtype if it statically
   matches the constraint of the subtype, or if both are static and the
-  constraint is compatible with the subtype.  A constraint is statically
+  constraint is compatible with the subtype. A constraint is statically
   compatible with an access or composite subtype if it statically matches the
-  constraint of the subtype, or if the subtype is unconstrained.  One subtype
-  is statically compatible with a second subtype if the constraint of the first
-  is statically compatible with the second subtype, and in the case of an
-  access type, if the second subtype excludes null, then so does the first.
-  {Also, if either subtype has a user-defined predicate, then the first is
-  statically compatible with the second only if they statically match, or if
-  both subtypes are static, and every value that obeys the predicate of the
-  first obeys the predicate of the second.}
+  constraint of the subtype, or if the subtype is unconstrained. [One subtype is
+  statically compatible with a second subtype if the constraint of the first is
+  statically compatible with the second subtype, and in the case of an access
+  type, if the second subtype excludes null, then so does the first.]
+
+  {Two statically matching subtypes are statically compatible with each other.
+  In addition, a subtype S1 is statically compatible with a subtype S2 if:
+
+      - S1's constraint is statically compatible with S2, and
+
+      - if S2 excludes null, so does S1, and
+
+      - either:
+
+        - all predicate clauses that apply to S2 apply also to S1, or
+
+        - both subtypes are static, and every value that obeys S1's
+          predicate also obeys S2's predicate.}
+
 
 Modify 5.4(7/3), so the full coverage rules for case statements
 take predicates into account:
@@ -474,11 +493,33 @@
 Also, "and then" and "or else" are not included (if they were,
 they would mean the same thing as "and" and "or").
 
+A membership_test with a list of values can be used as a Static_Predicate:
+
+    type Animal is (Dog, Cat, Shark, Boa_Constrictor);
+
+    subtype Pet is Animal with Static_Predicate => Pet in Dog | Cat;
+
+But now if Parrot is added to Animal, there is no warning that the programmer
+had better decide whether it makes a good pet.  It might be better to use
+a case_expression, in order to benefit from the full coverage rule:
+
+    subtype Pet is Animal with
+        Static_Predicate =>
+            (case Pet is
+                when Dog | Cat => True,
+                when Shark | Boa_Constrictor => False);
+
+Now adding Parrot to Animal causes a compile-time error on Pet.
+
+In other words, a case_expression whose type is Boolean
+represents a set, with a requirement that you specify
+what's IN the set and also what's NOT IN the set.
+
 Note that the last bullet in the definition of "predicate-static" allows
-parentheses, but not qualification.  Qualification within a static
+parentheses, but not qualification. Qualification within a static
 subexpression is OK, but qualification of a subexpression involving the current
 instance leads to a non-predicate-static predicate. For example, "Cur_Inst >
-Natural'(2)" is predicate-static, but "Boolean'(Cur_Inst > 2)" is not.  The
+Natural'(2)" is predicate-static, but "Boolean'(Cur_Inst > 2)" is not. The
 reason is to ensure (without knowing the value of the current instance) that
 predicate-static expressions cannot raise exceptions.
 

Questions? Ask the ACAA Technical Agent