CVS difference for ais/ai-00171.txt

Differences between 1.8 and version 1.9
Log of other versions for file ais/ai-00171.txt

--- ais/ai-00171.txt	2000/06/01 03:31:49	1.8
+++ ais/ai-00171.txt	2000/07/15 02:30:01	1.9
@@ -1,4 +1,4 @@
-!standard 03.08    (18)                               00-05-30  AI95-00171/08
+!standard 03.08    (18)                               00-07-13  AI95-00171/09
 !standard 03.03.01 (18)
 !standard 03.06    (22)
 !standard 04.03.01 (19)
@@ -57,7 +57,7 @@
   4.8(10)    creating heap objects via uninitialized allocators
 
   9.4(14)    creating a protected object (This one is supposed to be redundant
-                 with, but in fact appears to be inconsistent with 3.3.1.)
+                 with, but in fact the two appear to be inconsistent.)
 
 According to a strict reading, elaborating the per-object constraint would
 appear to involve reevaluating the non-per-object expressions (since there
@@ -85,7 +85,7 @@
 constraint are those determined during the original elaboration of the
 component definition as defined in 3.8(18).  Such expressions are not
 reevaluated during elaboration of the per-object constraint that occurs
-as part of object creation, despite any RM rules that state when a
+as part of object creation, despite any rules that state when a
 per-object constraint is elaborated (e.g, as part of evaluating an
 allocator or aggregate).
 
@@ -107,8 +107,8 @@
 
 !discussion
 
-There are two basic problems with the current RM wording regarding
-the elaboration of components with a per-object constraint.  The
+There are two basic problems with the current wording of the standard regarding
+the elaboration of components with a per-object constraint. The
 first is that the rules don't explain what is done with the values
 obtained from expressions that are not part of per-object expressions
 (as defined in 3.8(18)) or whether such expression are reevaluated when
@@ -121,28 +121,28 @@
 The intent was clearly that the values of the expressions evaluated as
 part of elaborating a component definition with a per-object constraint
 (3.8(18)) should be used later when creating an object of the containing
-type.  It would not make sense to discard the values already determined
+type. It would not make sense to discard the values already determined
 and to reevaluate the expressions (especially if they have side effects).
 The description in the rules for allocator and aggregate evaluation
 that states that a per-object constraint is elaborated should mention
 that only the per-object expressions are evaluated at that point and
 that the values for other expressions are those determined earlier
-when the type was elaborated.  (The description of the semantics
+when the type was elaborated. (The description of the semantics
 of elaborating per-object constraints should really be centralized
 in a single place, such as 3.8(18).)
 
 The rules for object declarations, allocator evaluation, and aggregate
 evaluation all fail to require the subtype compatibility check that
 occurs when a subtype indication is elaborated (and for object declarations
-even the constraint elaboration is omitted).  This check is certainly
-needed in these cases as well.  The fix for this oversight is to define
+even the constraint elaboration is omitted). This check is certainly
+needed in these cases as well. The fix for this oversight is to define
 each of these rules to include the elaboration of the subtype indications
 for components with per-object constraints (which also subsumes the
 elaboration of the constraint itself).
 
 One other minor gap is that the case of elaborating a named discriminant
 association within a per-object constraint is not covered by that rule
-in 3.8(18).  The rule as given only describes a single evaluation for
+in 3.8(18). The rule as given only describes a single evaluation for
 each expression of the constraint, but the intent is that for a named
 association the expression should be evaluated for each associated
 component.
@@ -222,6 +222,29 @@
 associated with the enclosing @fa<subtype_indication> or
 @fa<discrete_subtype_definition> are performed, including the subtype
 compatibility check (see 3.2.2), and the associated subtype is created.
+
+!corrigendum 4.08(10)
+
+@drepl
+@xbullet<If the designated type is composite, an object of the designated
+type is created with tag, if any, determined by the @fa<subtype_mark>
+of the @fa<subtype_indication>; any per-object constraints on
+subcomponents are elaborated and any implicit initial values for
+the subcomponents of the object are obtained as determined by the
+@fa<subtype_indication> and assigned to the corresponding subcomponents.
+A check is made that the value of the object belongs to the designated
+subtype. Constraint_Error is raised if this check fails. This check and the
+initialization of the object are performed in an arbitrary order.>
+@dby
+@xbullet<If the designated type is composite, an object of the designated
+type is created with tag, if any, determined by the @fa<subtype_mark>
+of the @fa<subtype_indication>; any per-object constraints on
+subcomponents are elaborated (see 3.8) and any implicit initial values for
+the subcomponents of the object are obtained as determined by the
+@fa<subtype_indication> and assigned to the corresponding subcomponents.
+A check is made that the value of the object belongs to the designated
+subtype. Constraint_Error is raised if this check fails. This check and the
+initialization of the object are performed in an arbitrary order.>
 
 !corrigendum 9.05.02(22)
 

Questions? Ask the ACAA Technical Agent