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

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

--- ai12s/ai12-0179-1.txt	2016/01/07 05:10:59	1.2
+++ ai12s/ai12-0179-1.txt	2016/08/30 03:03:25	1.3
@@ -1,4 +1,4 @@
-!standard 1.1.3(17/3)                                  16-01-04  AI12-0179-1/01
+!standard 1.1.3(17/3)                                  16-08-29  AI12-0179-1/02
 !class binding interpretation 16-01-04
 !status work item 16-01-04
 !status received 15-12-18
@@ -27,18 +27,31 @@
 Add after 1.1.3(17/3):
-The evaluation of a postcondition or type invariant defined in a
-language-defined unit shall not raise Assertion_Error, nor shall it fail a
-language-defined check.
-AARM Ramification: The evaluation could raise some exception explicitly, via a
-raise_expression, but it cannot evaluate to False in a conforming
-AARM Reason: This allows the standard to write semantic requirements as
-postconditions or invariants (which are invariably clearer than English prose
-would be) without opening the door to considering raising Assertion_Error
-as being conforming behavior.
+Any postcondition expression or type invariant expression occurring in the
+specification of a language-defined unit is enabled (see 6.1.1 and 7.3.2).
+AARM Ramification: The Assertion_Policy does not have an effect on such
+postconditions and invariants. This has no execution impact since such
+assertions shouldn't fail anyway (see the next rule).
+Any such associated postcondition check or type invariant check shall not fail
+at runtime. Such a check is said to fail if the evaluation of the assertion
+expression yields False, or if the evaluation propagates an exception other
+than in the following case: if the assertion expression is a raise_expression
+or has one or more raise_expressions as subexpressions, then if such a
+raise_expression is evaluated then the associated exception may be propagated.
+AARM Ramification: In other words, evaluating such an an assertion expression
+will not return a result of False, nor will it propagate an exception other
+than by evaluating a raise_expression which is syntactically all or part of
+the assertion expression.
+AARM To Be Honest: Evaluation of any expression might raise Storage_Error.
+AARM Reason: This allows the standard to express semantic requirements as
+postconditions or invariants (which are invariably clearer than English
+prose would be) while keeping it clear that failing the assertion check (or
+any other runtime check) is not conforming behavior.

Questions? Ask the ACAA Technical Agent