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

--- ai05s/ai05-0153-1.txt	2010/04/29 04:18:06	1.8
+++ ai05s/ai05-0153-1.txt	2010/05/04 03:55:06	1.9
@@ -68,7 +68,8 @@
 The language-defined aspect Predicate is defined for subtypes.
 The expected type for a Predicate expression is any boolean type.
 
-A Predicate may be specified on a type_declaration or a subtype_declaration; if none is given, an implicit "with Predicate => True" is assumed.
+A Predicate may be specified on a type_declaration or a subtype_declaration; if
+none is given, an implicit "with Predicate => True" is assumed.
 The predicate of a subtype is defined as follows:
 
     - For a (first) subtype defined by a derived type declaration, the
@@ -90,7 +91,9 @@
     [???I don't think we need to say anything about ranges or discrete_ranges,
     here.]
 
-[Editor's note: The predicate has no effect on the static or dynamic semantics of the subtype indication except as noted here. In particular, it has no effect on the range of scalar subtypes.]
+[Editor's note: The predicate has no effect on the static or dynamic semantics
+of the subtype indication except as noted here. In particular, it has no effect
+on the range of scalar subtypes.]
 
 
                                Dynamic Semantics
@@ -170,17 +173,6 @@
 
 [End of 3.2.4.]
 
-6.4.1(13) says:
-
-13      * For an access type, the formal parameter is initialized from the
-          value of the actual, without a constraint check;
-
-Change it to:
-
-13      * For an access type, the formal parameter is initialized from the
-          value of the actual, without any constraint, null-exclusion, or
-          predicate checks;
-
 Modify 4.5.2(29):
 
 The tested type is scalar, and the value of the simple_expression belongs
@@ -241,13 +233,17 @@
 
 ---
 
-The model here is that a predicate has *no* effect on the static or dynamic semantics of a constraint. That is, if a predicate is applied to an indefinite type, the resulting subtype is indefinite. If a predicate is applied to an unconstrained subtype, th
e resulting subtype is unconstrained. And so on.
+The model here is that a predicate has *no* effect on the static or dynamic semantics
+of a constraint. That is, if a predicate is applied to an indefinite type, the
+resulting subtype is indefinite. If a predicate is applied to an unconstrained
+subtype, the resulting subtype is unconstrained. And so on.
 
 This mirrors the semantics of null exclusions (which also are not constraints).
 
 ---
 
-We define predicates to be part of static matching, so that subtypes with different predicates are not considered identical.
+We define predicates to be part of static matching, so that subtypes with different
+predicates are not considered identical.
 
 ---
 
@@ -1150,7 +1146,8 @@
 > It's so frustrating when a programmer says "How come I can't add 2
 > plus 2 in Ada", and as a language lawyer, I'm forced to say, "Because
 > in a generic discriminanted select statement, a requeue might blah
-> blah blah."  And the programmer says, I don't WANT no stinkin' discriminated requeue blah... -- I just want to add 2+2!
+> blah blah."  And the programmer says, I don't WANT no stinkin'
+> discriminated requeue blah... -- I just want to add 2+2!
 >
 > For example, in GNAT we have (some comments removed):
 >
@@ -1255,7 +1252,8 @@
 Let's ignore reals for a moment and focus on discretes.
 (Although
     subtype Positive_Float is Float range 0.0 .. Float'Last
-      with predicate Positive_Float /= 0.0; does make me wonder about the value of Positive_Float'First).
+      with predicate Positive_Float /= 0.0; does make me wonder about the value
+           of Positive_Float'First).
 
 A subtype defines a subset of the set of values of the basetype.
 
@@ -1372,7 +1370,8 @@
 test:
 
 subype Overloadable_Kind is Entity_Kind with
-   predicate =>  Overloadable_Kind in (E_Enumeration_Literal, E_Function, E_Procedure, E_Entry)
+   predicate =>  Overloadable_Kind in (E_Enumeration_Literal, E_Function, E_Procedure,
+                                       E_Entry)
 
 ****************************************************************
 
@@ -1845,7 +1844,9 @@
 > to make it a bounded error (or erroneous??) if it is not one; I think
 > that is the most that we could agree to here. But we don't need to
 > agree to that at all, because all we need to do is say it as I
-> described above (no mention of functions is needed). Let's not waste our time arguing about what is a pure function since it isn't important for this concept.
+> described above (no mention of functions is needed). Let's not waste our
+> time arguing about what is a pure function since it isn't important for
+> this concept.
 
 We haven't talked much about this point yet.
 
@@ -2249,7 +2250,8 @@
 > allowed) cannot be depended upon. Note that this isn't the same as
 > being allowed to check the predicate anywhere at all; there has to be
 > some use of a value or object that has the subtype. That's necessary
-> so that it is possible to write the predicate without an evaluation of itself being triggered.
+> so that it is possible to write the predicate without an evaluation of itself
+> being triggered.
 
 I don't understand that last sentence.
 
@@ -2337,7 +2339,8 @@
 
 Ah, I see.
 
-This is inconsistent with similar cases, where we just make it a run time error, and trust compilers to give warnings when statically known.
+This is inconsistent with similar cases, where we just make it a run time
+error, and trust compilers to give warnings when statically known.
 
 > Add after 3.6.1(5):
 >
@@ -2447,7 +2450,8 @@
 > One might expect to have "24680" printed, but since the constraints
 > are unchanged, "1234567890" would actually be printed. Because of this
 > weird behavior, we do not allow predicates on index subtypes. In order
-> to avoid breaking the contract model, we raise Program_Error in generic bodies if the subtype has a predicate.
+> to avoid breaking the contract model, we raise Program_Error in generic
+> bodies if the subtype has a predicate.
 
 Here's a radical notion: Raise P_E when an instance is elaborated, if it
 contains any such evil things, even in unreachable/unreached code.