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

--- ai05s/ai05-0153-3.txt	2011/02/08 08:21:06	1.5
+++ ai05s/ai05-0153-3.txt	2011/02/10 05:56:56	1.6
@@ -166,9 +166,9 @@
 
     - a static expression that does not raise any exception;
 
-    - a membership test whose left-hand side is the current instance,
-      and whose right-hand side is static;
-[Author's Question: Does that allow "S in (Foo | Bar | Baz)"?]
+    - 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 call to a predefined equality or ordering operator, where one operand
       is the current instance, and the other is a static expression;
@@ -216,11 +216,8 @@
 
                           Implementation Permissions
 
-A predicate check may be omitted if the subtype with the predicate statically
-matches the nominal subtype of the value being checked.
-[???I'm not sure this is the right rule. But I don't think the exact rule
-here is important, and I'd prefer to argue about it after dealing with
-all the other stuff.]
+A Static_Predicate check may be omitted if the subtype with the predicate
+statically matches the nominal subtype of the value being checked.
 
 AARM Reason: Well-behaved predicates should not have side effects that matter,
 so omitting the check is pretty harmless. It is possible to write
@@ -232,11 +229,11 @@
 NOTE: A predicate clause does not cause a subtype to be considered
 "constrained".
 
-NOTE: A predicate is not necessarily True for all objects of the subtype at all
-times. Predicates are checked as specified above, but can become False at other
-times. For example, the predicate of a record is not checked when a component
-is modified. Similarly to constraints, predicates can be False for
-uninitialized variables and other invalid values.
+NOTE: Similarly to constraints, a Static_Predicate is always True for all
+objects of the type, except in the case of uninitialized variables and other
+invalid values. A Dynamic_Predicate, on the other hand, is checked as specified
+above, but can become False at other times. For example, the predicate of a
+record is not checked when a subcomponent is modified.
 
 [End of 3.2.4.]
 
@@ -322,10 +319,9 @@
   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 both subtypes are static, and
-  every value that obeys the predicate of the first obeys the predicate of the
-  second.}
-[Author's question: Is that reasonable to implement?]
+  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.}
 
 Modify 5.4(7/3), so the full coverage rules for case statements
 take predicates into account:
@@ -491,10 +487,10 @@
 An earlier version of this AI proposed a single Predicate aspect, which could
 allow static subtypes or not, depending on whether the expression happened to
 be predicate-static. We decided to split it into two aspects, Static_Predicate
-and Dynamic_Predicate, because otherwise, if you change a static predicate to a
-nonstatic one, faraway parts of your program can become illegal.
+and Dynamic_Predicate, in part because otherwise, if you change a static
+predicate to a nonstatic one, faraway parts of your program can become illegal.
 
-The following arguments against the split were rejected:
+The following arguments against this argument were rejected:
 
     - They won't change their run-time behavior, just become illegal.
 
@@ -511,6 +507,13 @@
       "C: static constant Integer := ...", so why should we
       do so for predicates?
 
+Another, perhaps more compelling reason for the split is that Static_Predicates
+are like constraints, in that they can only become False in the presence of
+invalid values (ignoring erroneous executions, of course). In contrast,
+Dynamic_Predicates are more dangerous to rely on, because they can become False
+in more cases: for example, the Dynamic_Predicate of a record is not checked
+when components of that record or global variables are modified.
+
 ---
 
 Interactions with generics.
@@ -1656,133 +1659,3 @@
 
 ****************************************************************
 
-[The following mail should go into a new AI, still TBD:]
-
-From: Bob Duff
-Sent: Monday, January 24, 2011  9:52 AM
-
-> P.S. should we have a restriction
->
-> No_Implementation_Aspects
-
-Yes, good idea.
-
-****************************************************************
-
-From: Bob Duff
-Sent: Monday, January 24, 2011  10:02 AM
-
-By the way, obviously some folks would like to forbid Dynamic_Predicate, so
-there should be a restriction for that.  Instead of doing it piecemeal, we
-should do like we did for No_Dependence, and have a general feature for
-forbidding any aspect.  Something like:
-
-    pragma Restrictions (No_Aspect => Dynamic_Predicate);
-
-We could have an enum type somewhere that lists all the aspect names.  Or we
-could just allow an "aspect_identifier" there, without involving visibility --
-like pragma arguments.  For aspects that are also attributes or pragmas, the
-restriction should forbid both forms.
-
-I've got no problem with self-imposed or project-imposed restrictions!  If,
-someday, some customer requests No_Evil_Predicates, I expect AdaCore would
-implement it (if we can come up with a coherent definition of "evil").
-
-****************************************************************
-
-From: Tucker Taft
-Sent: Monday, January 24, 2011  10:19 AM
-
-Or perhaps something like:
-
-   pragma Restrictions(No_Aspect_Specification => Dynamic_Predicate);
-
-to be analogous to "No_Dependence => ...".
-
-****************************************************************
-
-From: Bob Duff
-Sent: Monday, January 24, 2011  10:38 AM
-
-Yes, that's better.  For those aspects that are also attributes, you probably
-want to restrict the specification, but not the query.
-
-****************************************************************
-
-From: Robert Dewar
-Sent: Tuesday, January 25, 2011   6:14 AM
-
-> Or perhaps something like:
->
->     pragma Restrictions(No_Aspect_Specification =>
-> Dynamic_Predicate);
->
-> to be analogous to "No_Dependence =>  ...".
-
-Can't we just have
-
-   No_Aspect => name
-
-I see no advantage to reader or writer in adding the Specification part here,
-especially if it also bans a corresponding pragma or attribute.
-
-****************************************************************
-
-From: Robert Dewar
-Sent: Tuesday, January 25, 2011   6:15 AM
-
-> Yes, that's better.  For those aspects that are also attributes, you
-> probably want to restrict the specification, but not the query.
->
->> to be analogous to "No_Dependence =>  ...".
-
-OK, I see, grumble, I guess the long name will have to do
-
-****************************************************************
-
-From: Robert Dewar
-Sent: Monday, July 26, 2010   7:46 PM
-
-Implementations are allowed to add grandchildren to Ada etc. And GNAT
-takes advantage of this, e.g. to add the encoding packages to earlier
-versions of Ada.
-
-But this creates portability problems, we should really have a
-restriction to prevent this, in the style of No_Implementation_Pragmas.
-
-How about No_Implementation_Units
-
-?
-
-I am not really suggesting a new AI at this stage, just some guidance
-on whether this is a good idea so that implementations can adopt it
-(and then we can put it into Ada 2019 :-))
-
-****************************************************************
-
-From: Tucker Taft
-Sent: Monday, July 26, 2010   8:14 PM
-
-This sounds like a very good idea.
-Users are often confused about what
-packages are "standard" Ada and what
-are not.
-
-Does this also cover System.* and Interfaces.*?
-One rule might be to disallow any package that starts with "Ada", "System",
-or "Interfaces" that is not in the reference manual.  These are the ones
-that confuse users.
-
-****************************************************************
-
-From: Robert Dewar
-Sent: Monday, July 26, 2010   8:33 PM
-
-Right, that's what I had in mind.
-
-And the idea would be in particular to forbid use of RM packages in an
-inappropriately earlier version of Ada (e.g. using the string encoding packages
-in Ada 2005 mode). Of course I know that can't be part of the standard, but
-that would be the encouraged usage (and is what GNAT intends to do).
-
-****************************************************************