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

Differences between 1.3 and version 1.4
Log of other versions for file 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
+!standard 11.4.2(23.1/3)
 !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
 !priority Low
@@ -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):
+
+Implementation Requirements
+
 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.
 
 !discussion
 
@@ -59,13 +66,12 @@
 no other exceptions. If we don't want to do that, we could simplify the wording
 to just:
 
-  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
 than Assertion_Error.)
 
-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.
+
 
 !ASIS
 

Questions? Ask the ACAA Technical Agent