CVS difference for ai12s/ai12-0054-2.txt

--- ai12s/ai12-0054-2.txt	2013/06/11 01:01:49	1.2
+++ ai12s/ai12-0054-2.txt	2013/07/06 00:01:21	1.3
@@ -1,4 +1,4 @@
-!standard 3.2.4(14/3)                              13-05-31    AI12-0054-2/01
+!standard 3.2.4(14/3)                              13-06-14    AI12-0054-2/02
 !standard 3.2.4(30/3)
 !class binding interpretation 13-05-31
 !status work item 13-05-31
@@ -22,8 +22,8 @@
 
 However, this feature doesn't work properly for predicates, because predicates
 are evaluated by membership tests, so we would get spurious failures. Should
-these spurious failures be removed from the language, so that there is a mechanism
-for specifying the exception raised by a predicate failure? (Yes.)
+these spurious failures be removed from the language, so that there is a
+mechanism for specifying the exception raised by a predicate failure? (Yes.)
 
 !recommendation
 
@@ -37,55 +37,41 @@
 aspect_specification (see 13.1.1):
 
 Predicate_Failure
-   This aspect specifies an expression that will be evaluated if a predicate check
-   for the subtype fails; it shall be specified by an expression, called the
-   predicate failure expression. If not specified for a subtype, the
-   predicate failure expression for the subtype is a raise_expression that
-   raises Assertion_Error.
+   This aspect specifies an expression that will be evaluated if a predicate
+   check for the subtype fails; it defines the Message associated to the
+   occurrence of Assertion_Error wich is raised by the failure of the condition.
 
 Name Resolution Rules
 
-The expected type for a precondition or postcondition expression is Boolean.
+The expected type for a precondition or postcondition expression is String.
 
-[Editor's note: We need to specify the type so that the expression can be resolved (a
-raise_expression has "any type", so we need a specific type here). I considered
-restricting these expressions to a single raise_expression via a Legality Rule,
-but I can't think of any particularly good reason to do so. Note that the current
-instance of the subtype is visible in the Predicate_Failure expression -- this is
-useful in the exception message part of a raise_expression. So one could imagine
-calling a function on that value to log the bad value before raising a failure
-exception. As such, the value of allowing any expression seems to be non-zero,
-and it doesn't seem to cost anything extra. In any case, the Boolean result
-is discarded.]
-
-Remove "Assertion_Error is raised if any of these checks fail." from 3.2.4(30/3).
-
-Add after 3.2.4(30/3):
-
-If any of these checks fail, the Predicate_Failure expression of the subtype that
-includes the specification of the predicate that failed (returned False) is evaluated,
-and the result (if any) is discarded. Redundant[If none is specified, Assertion_Error
-is raised.]
-
-[Editor's note: I don't know if the above is sufficiently detailed. Probably we would
-want to define the details of a predicate check more tightly, possibly similarly
-to the way it is described in AI12-0071-1. Note that we're assuming some solution to
-the problems noted in that AI is adopted, else this problem is not really solved.
-I'm also a bit worried about 11.6 effects with this wording; we don't want compilers
-optimizing away this evaluation unless it truly has no effect (exceptions should
-always be raised here) -- but as the actual returned result has no effect on the
-program, it would seem that 11.6 would allow the entire expression to be ignored.
-I'd hate to put a "notwithstanding" into this wording, but if we have to do that
-to effectively delete 11.6.]
+Change the end of 3.2.4(31/3) as follows:
+"Assertion_Error is raised {with the message defined by evaluating the
+aspect Predicate_Failure (or the empty string if not specified)} if
+any of these checks fail."
 
 !discussion
 
-Note that Predicate_Failure is not involved when a predicate is evaluated in a membership
-or Valid attribute. This is how we get our cake and eat it too in this case.
+Note that Predicate_Failure is not involved when a predicate is evaluated in a
+membership or Valid attribute. This is how we get our cake and eat it too in
+this case.
+
+The expression of the Predicate_Failure aspect can be as simple as a
+string litteral if all that is desired is to change the message; note
+that the current instance of the subtype is visible in the
+Predicate_Failure expression -- this can be useful in the exception
+message. On the other hand, the expression could be a complicated
+function call to log the bad value for example.
+
+If the evaluation of the expression raises an exception (an especially
+if it is a raise expression), the exception will propagate normally,
+thus achieving the effect of the predicate raising an expression
+different from Assertion_Error.
+
+If it is necessary to raise multiple exceptions for different failures, it is
+necessary to define multiple subtypes. For instance, Text_IO could define
+subtypes like:
 
-If it is necessary to raise multiple exceptions for different failures, it is necessary
-to define multiple subtypes. For instance, Text_IO could define subtypes like:
-
    subtype Open_File_Type is File_Type
       with Dynamic_Predicate => Is_Open (Open_File_Type),
            Predicate_Failure => raise Status_Error;
@@ -103,7 +89,7 @@
 A simpler alternative would be to simply have a Predicate_Failure_Exception
 aspect, which just specifies the exception. In that case, however, we've
 lost the ability to give an exception message. Thus we prefer the given
-solution (possibly with a Legality Rule to limit it to raise_expressions only).
+solution.
 
 !ACATS Test