CVS difference for ai12s/ai12-0179-1.txt
--- ai12s/ai12-0179-1.txt 2016/08/30 03:03:25 1.3
+++ ai12s/ai12-0179-1.txt 2016/11/11 01:37:13 1.4
@@ -1,5 +1,8 @@
-!standard 1.1.3(17/3) 16-08-29 AI12-0179-1/02
+!standard 1.1.3(17/3) 16-11-10 AI12-0179-1/03
!class binding interpretation 16-01-04
+!status Amendment 1-2012 16-11-10
+!status ARG Approved 10-0-0 16-10-08
!status work item 16-01-04
!status received 15-12-18
@@ -27,6 +30,13 @@
Add after 1.1.3(17/3):
+The implementation of a language-defined unit shall abide by all postconditions
+and type invariants specified for the unit International Standard (see 11.4.2).
+Add after 11.4.2(23.1/3):
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).
@@ -34,12 +44,9 @@
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.
+The evaluation of any such postcondition or type invariant expression shall
+either yield True or propagate an exception from a raise_expression that
+appears within the assertion expression.
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
@@ -51,7 +58,7 @@
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.
+any other run time check) is not conforming behavior.
@@ -59,13 +66,12 @@
no other exceptions. If we don't want to do that, we could simplify the wording
- The evaluation of a postcondition or type invariant defined in a
- language-defined unit shall not raise an exception.
+ The evaluation of any such postcondition or type invariant shall yield True.
(and delete the Ramification, adjusting the Reason to say "an exception" rather
-We include type invariants as in normal usage, they act as implicit
+We include type invariants as in normal usage they act as implicit
postconditions. The client of a package should not be able to cause an
invariant to fail.
@@ -80,6 +86,7 @@
to a reader of the Standard (it would not be immediately apparent whether they
apply to the client or to the implementation), so we do not include them here
and suggest that the Standard avoid using them.
Questions? Ask the ACAA Technical Agent