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

Differences between 1.16 and version 1.17
Log of other versions for file ai12s/ai12-0127-1.txt

--- ai12s/ai12-0127-1.txt	2017/11/30 04:18:01	1.16
+++ ai12s/ai12-0127-1.txt	2017/12/14 23:45:48	1.17
@@ -1,8 +1,16 @@
-!standard 4.3(2)                                    17-11-21    AI12-0127-1/10
+!standard 4.3(2)                                    17-12-08    AI12-0127-1/11
+!standard 4.3(3/2)
 !standard 4.3(4)
-!standard 4.3.3(3)
+!standard 4.3.1(9)
+!standard 4.3.1(15/3)
+!standard 4.3.1(16/4)
+!standard 4.3.1(17/5)
+!standard 4.3.1(17.1/2)
+!standard 4.3.3(4)
+!standard 4.3.3(14)
+!standard 4.3.3(17)
 !standard 4.3.4(0)
-!standard 7.5(2.10/3)
+!standard 7.5(2.6/2)
 !class Amendment 14-08-21
 !status Amendment 1-2012 17-11-21
 !status ARG Approved 8-0-0  17-10-14
@@ -70,12 +78,9 @@
   aggregate ::= record_aggregate | extension_aggregate | array_aggregate
 
 with:
-  aggregate ::= record_aggregate    |
-                extension_aggregate |
-                array_aggregate     |
-                delta_aggregate
+  aggregate ::= record_aggregate | extension_aggregate | array_aggregate | delta_aggregate
 
-Replace 4.3(3):
+Replace 4.3(3/2):
 
   The expected type for an aggregate shall be a single array type,
   record type, or record extension.
@@ -94,19 +99,69 @@
   A record aggregate or extension aggregate shall not be of a class-wide
   type.
 
-Add after 4.3.1(9):
+Modify 4.3.1(9):
 
-  Each selector_name in a record_component_association of a
-  record_delta_aggregate shall denote a nondiscriminant component of
-  the record type.
-
-[Editor's note: We don't use "needed" here so that there is no completeness
-requirement in a delta aggregate. But that means the 2nd half of the first
-sentence of 4.3.1(16) doesn't apply; we have to specifically have Legality
-Rules to prevent giving the same component twice ("distinct" below) and 
-giving components from two variants.]
+  For the record_component_association_list of a record_aggregate, all
+  components of the composite value defined by the aggregate are *needed*;
+  for the association list of an extension_aggregate, only those components
+  not determined by the ancestor expression or subtype are needed (see 4.3.2).
+  Each *component_*selector_name in a record_component_association {of a
+  record_aggregate or extension_aggregate} shall denote a needed component
+  (including possibly a discriminant).{ Each *component_*selector_name in a
+  record_component_association of a record_delta_aggregate (see 4.3.4) shall
+  denote a nondiscriminant component of the type of the aggregate.
+
+  AARM Reason: We don't define "needed" for record_delta_aggregates so that
+  there is no completeness requirement. But that means that we need to ensure
+  that the rules using "needed" so that they don't appear to apply to
+  record_delta_aggregates, and we also need Legality
+  Rules to prevent giving the same component twice and
+  giving components from two variants.
+
+
+Replace 4.3.1(15/3) with:
+
+  A record_component_association_list shall be /null record/ only if the list
+  occurs in a record_aggregate or extension_aggregate, and there are no
+  components needed for that list.
+
+    AARM Ramification: /null record/ is not allowed at all in a
+    record_delta_aggregate.
+
+Replace 4.3.1(16/4) with (2 paragraphs):
+
+  For a record_aggregate or extension_aggregate, each
+  record_component_association other than an others choice with a <> shall have
+  at least one associated component, and each needed component shall be
+  associated with exactly one record_component_association.
+  For a record_delta_aggregate, each component_selector_name of each
+  component_choice_list shall denote a distinct nondiscriminant component of
+  the type of the aggregate.
+
+  If a record_component_association with an expression has two or more
+  associated components, all of them shall be of the same type, or all of them
+  shall be of anonymous access types whose subtypes statically match. In
+  addition, Legality Rules are enforced separately for each associated
+  component.
+
+Modify the start of 4.3.1(17/5):
+
+  {For a record_aggregate or extension_aggregate, if}[If] a variant_part ...
+
+Add after 4.3.1(17.1/2):
+
+  A record_component_association of the record_component_association_list
+  of a record_delta_aggregate shall not:
+      * use the compound delimiter <> (box) rather than an expression;
+      * have an expression of a limited type;
+      * omit the component_choice_list; or
+      * have a component_choice_list that is an /others/ choice.
+
+  For a record_delta_aggragate, no two component_selector_names shall
+  denote components declared within different variants of the same
+  variant part.
 
-Replace 4.3.3(3):
+Replace 4.3.3(4):
   named_array_aggregate ::=
     (array_component_association {, array_component_association})
 
@@ -116,6 +171,12 @@
   array_component_association_list ::=
     array_component_association {, array_component_association}
 
+Add after 4.3.3(14):
+
+   * For the *base_*expression of a delta_aggregate, if the nominal subtype
+     of the delta_aggregate is a constrained array subtype, the applicable
+     index constraint is the constraint of the subtype;
+
 In 4.3.3(17/5) replace:
    ... only if it is the single discrete_choice of its
    discrete_choice_list, and there is only one
@@ -142,8 +203,7 @@
 
 Syntax
 
-  delta_aggregate ::= record_delta_aggregate |
-                      array_delta_aggregate
+  delta_aggregate ::= record_delta_aggregate | array_delta_aggregate
 
   record_delta_aggregate ::=
     (*base_*expression with delta record_component_association_list)
@@ -153,101 +213,92 @@
 
 Name Resolution Rules
 
-The expected type for a record_delta_aggregate shall be a single record type
-or record extension.
+The expected type for a record_delta_aggregate shall be a single descendant
+of a record type or record extension.
 
 The expected type for an array_delta_aggregate shall be a single array type.
 
 The expected type for the *base_*expression of any delta_aggregate is
 the type of the enclosing delta_aggregate.
 
-For a record_delta_aggregate, the expected type and applicable index
-constraint of the expression in each record_component_association is
-defined as for a record_component_association occurring within a
-record aggregate.
+@Redundant[The Name Resolution Rules and Legality Rules for each
+record_component_association of a record_delta_aggregate are as defined in
+4.3.1.]
 
 For an array_delta_aggregate, the expected type for each
 discrete_choice in an array_component_association is the index type of
 the type of the delta aggregate.
 
-The expected type and applicable index constraint of the expression in
-array_component_association is defined as for an
-array_component_association occurring within an array aggregate of the
-type of the delta aggregate.
+The expected type of the expression in array_component_association is defined
+as for an array_component_association occurring within an array aggregate of
+the type of the delta aggregate.
 
 Legality Rules
 
-For a record_delta_aggregate, a record_component_association_list
-shall not be null record. A record_component_association of the
-record_component_association_list of a record_delta_aggregate
-shall not use the box symbol <>, nor shall its component_choice_list
-use others.
-
-For a record_delta_aggregate, each component_selector_name of each
-component_choice_list shall denote a distinct nondiscriminant component of
-the type of the delta aggregate. No two such component_selectors shall
-denote components declared within different variants of the same variant part.
-
-The types of components in record_component_associations follow the same
-rules as they do for record aggregates (see 4.3.1).
-
 For an array_delta_aggregate, the array_component_association shall not use
 the box symbol <>, and the discrete_choice shall not be others.
 
 For an array_delta_aggregate, the dimensionality of the type of the
 delta aggregate shall be 1.
 
-For a delta_aggregate the expression in a record_component_association or a
-array_component_association shall not be of a limited type.
+For an array_delta_aggregate, the *base_*expression and each expression in
+every array_component_association shall be of a nonlimited type.
 
-For an array_delta_aggregate, the *base_*expression shall be of a nonlimited
-type.
-
 AARM Ramification: The *base_*expression of a record_delta_aggregate may be of
-a limited type (for example a record with limited components), the above rule
-only makes sure we do not assign to a limited component. We do not allow the
-*base_*expression of an array_delta_aggregate to be of a limited type as this
-is a useless construct (you would not be able to update anything as the
-components necessarily are also limited except in pathological cases).
+a limited type (for example a record with limited components), as it is not
+restricted. A rule in 4.3.1 ensures we do not assign to a limited component.
+We do not allow any part of an array_delta_aggregate to be of a limited type,
+even the *base_*expression, as this is a useless construct (you would not be
+able to update anything as the components necessarily are also limited except
+in pathological cases).
 
 Dynamic Semantics
 
 The evaluation of a delta_aggregate begins with evaluating the
 *base*_expression of the delta_aggregate and using that value to create and
-initialize the aggregate's anonymous object.
-
-AARM Discussion: This follows the same rules as for initializing the object
-denoted by 'Old (see 6.1.1) except in the case where the anonymous
-object is built in place (see 7.6).
-
-Next, for each component for which an expression is provided, the
-expression is evaluated and assigned to that component of the object.
-In the case of an array component, the associated index expression is
-also evaluated and used in determining the target component just as in
-any array indexing operation. As with any aggregate, evaluation of a
-delta_aggregate then denotes the associated anonymous object.
-
-AARM Ramification: As with 'Old, this means that the underlying tag (if any)
-associated with the delta aggregate is that of the expression in
-delta_aggregate and not that of the nominal type of the expression in
-delta_aggregate.
-
-AARM To Be Honest: The anonymous object associated with the evaluation of a
-delta aggregate begins its life as a variable, not a constant (Ada RM 3.3
-notwithstanding). This must be the case because the object is initialized
-and then subsequently modified. After evaluation of the delta aggregate is
-complete, the object is a constant object. This is similar to the way that
-an extended return statement can provide a variable view of an object that
-will eventually be a constant object after the function returns its result
-via "build in place".
-
-For a record_delta_aggregate, the order of the subsequent assignments
-is unspecified. For an array_delta_aggregate, the subsequent
-assignments (including all associated expression evaluations) are
-performed in the order in which the array_component_association_list
-is given; within a single array_component_association, in the order of
-the discrete_choice_list; and within the range of a single
-discrete_choice, in ascending order.
+initialize the anonymous object of the aggregate. The bounds of the anonymous
+object of an array_delta_aggregate and the discriminants and tag (if any) of
+the anonymous object of a record_delta_aggregate are those of the
+*base_*expression.
+
+  AARM Ramification: This is the same anonymous object as described in
+  7.6, 'Assignment and Finalization'; in particular, it might be required
+  to be built in place.
+
+  AARM Ramification: This requires that the underlying tag (if any)
+  associated with the delta aggregate is that of the *base_*expression in
+  the delta_aggregate and not that of the nominal type of the *base_*expression
+  in the delta_aggregate.
+
+  AARM To Be Honest: The anonymous object associated with the evaluation of a
+  delta aggregate begins its life as a variable, not a constant (3.3
+  notwithstanding). This must be the case because the object is initialized
+  and then subsequently modified. After evaluation of the delta aggregate is
+  complete, the object is a constant object. This is similar to the way that
+  an extended return statement can provide a variable view of an object that
+  will eventually be a constant object after the function returns its result.
+
+For a record_delta_aggregate, for each component associated with each
+record_component_association (in an unspecified order):
+   * if the associated component belongs to a variant, a check is made that the
+     values of the discriminants are such that the anonymous object has this
+     component. The exception Constraint_Error is raised if this check fails.
+   * the expression of the record_component_association is
+     evaluated, converted to the nominal subtype of the associated component,
+     and assigned to the component of the anonymous object.
+
+For an array_delta_aggregate, for each discrete_choice of each
+array_component_assocation (in the order given in the enclosing
+discrete_choice_list and array_component_assocation_list, respectively) the
+discrete_choice is evaluated; for each represented index value (in ascending
+order, if the discrete_choice represents a range):
+   * the index value is converted to the index type of the array type.
+   * a check is made that the index value belongs to the index range of the 
+     anonymous object of the aggregate; Constraint_Error is raised if this 
+     check fails.
+   * the component expression is evaluated, converted to the array component
+     subtype, and assigned to the component of the anonymous array object
+     identified by the index value.
 
 Examples
 
@@ -277,7 +328,7 @@
                    Y => P.Y + Y);
   --  see 3.9 for declaration of type Point
 
-Add after 7.5(2.10/3):
+Add after 7.5(2.6/2):
 
 * the *base_*expression of a record_delta_aggregate  (see 4.3.4)
 
@@ -285,7 +336,7 @@
 
 SPARK 2014 defines an attribute Update for this purpose. Using this
 attribute, the call in the question can be expressed as:
-   Foo (R'Update (Color => Black));
+   Foo (R'Update (Colour => Black));
 
 We believe it is better to use aggregate syntax for this, as we certainly want
 aggregate semantics relative to temporaries, build-in-place, limited types,
@@ -295,7 +346,8 @@
 Multi-dimensional array aggregates
 ----------------------------------
 
-This will be a separate AI.
+This will be a separate AI as it is much more complex than the record and
+single dimension array cases.
 
 Discriminants
 -------------
@@ -303,7 +355,7 @@
 
 We decided "No".
 
-They would have to be listed first, and require any variant section 
+They would have to be listed first, and require any variant section
 to be completely updated. (Indeed, all discriminant-dependent components
 would have to be present.)
 
@@ -322,6 +374,296 @@
 
 Also see the examples in the !wording section.
 
+!corrigendum 4.3(2)
+
+@drepl
+@xcode<@fa<aggregate>@fa< ::= >@fa<record_aggregate | extension_aggregate | array_aggregate>>
+@dby
+@xcode<@fa<aggregate>@fa< ::= >@fa<record_aggregate | extension_aggregate | array_aggregate | delta_aggregate>>
+
+!corrigendum 4.3(3/2)
+
+@drepl
+The expected type for an @fa<aggregate> shall be a single array type, record
+type, or record extension.
+@dby
+The expected type for a @fa<delta_aggregate> shall be a single array type, or
+a single descendant of a record type or of a record extension.
+The expected type for any other @fa<aggregate> shall be a single array type,
+record type, or record extension.
+
+!corrigendum 4.3(4)
+
+@drepl
+An @fa<aggregate> shall not be of a class-wide type.
+@dby
+A @fa<record_aggregate> or @fa<extension_aggregate> shall not be of a
+class-wide type.
+
+!corrigendum 4.3.1(9)
+
+@drepl
+For the @fa<record_component_association_list> of a @fa<record_aggregate>,
+all components of the composite value defined by the aggregate are @i<needed>;
+for the association list of an @fa<extension_aggregate>, only those components
+not determined by the ancestor expression or subtype are needed (see 4.3.2).
+Each @fa<selector_name> in a @fa<record_component_association> shall denote a
+needed component (including possibly a discriminant).
+@dby
+For the @fa<record_component_association_list> of a @fa<record_aggregate>,
+all components of the composite value defined by the aggregate are @i<needed>;
+for the association list of an @fa<extension_aggregate>, only those components
+not determined by the ancestor expression or subtype are needed (see 4.3.2).
+Each @i<component_>@fa<selector_name> in a @fa<record_component_association>
+of a @fa<record_aggregate> or @fa<extension_aggregate> shall denote a
+needed component (including possibly a discriminant). Each
+@i<component_>@fa<selector_name> in a @fa<record_component_association> of a
+@fa<record_delta_aggregate> (see 4.3.4) shall
+denote a nondiscriminant component of the type of the @fa<aggregate>.
+
+!corrigendum 4.3.1(15/3)
+
+@drepl
+The reserved words @b<null record> may appear only if there are no
+components needed in a given @fa<record_component_association_list>.
+@dby
+A @fa<record_component_association_list> shall be @b<null record> only if the
+list occurs in a @fa<record_aggregate> or @fa<extension_aggregate>, and there
+are no components needed for that list.
+
+!corrigendum 4.3.1(16/4)
+
+@drepl
+Each @fa<record_component_association> other than an @b<others> choice with a
+<@> shall have at least one associated component, and each needed component
+shall be associated with exactly one @fa<record_component_association>. If a
+@fa<record_component_association> with an @fa<expression> has two or more
+associated components, all of them shall be of the same type, or all of them
+shall be of anonymous access types whose subtypes statically match. In
+addition, Legality Rules are enforced separately for each associated component.
+@dby
+For a @fa<record_aggregate> or @fa<extension_aggregate>, each
+@fa<record_component_association> other than an @b<others> choice with a <@>
+shall have at least one associated component, and each needed component shall be
+associated with exactly one @fa<record_component_association>.
+For a @fa<record_delta_aggregate>, each @I<component_>@fa<selector_name> of each
+@fa<component_choice_list> shall denote a distinct nondiscriminant component of
+the type of the aggregate.
+
+If a @fa<record_component_association> with an @fa<expression> has two or more
+associated components, all of them shall be of the same type, or all of them
+shall be of anonymous access types whose subtypes statically match. In
+addition, Legality Rules are enforced separately for each associated
+component.
+
+!corrigendum 4.3.1(17/5)
+
+@drepl
+The value of a discriminant that governs a @fa<variant_part> @i<P> shall
+be given by a static expression, unless @i<P> is nested within a
+@fa<variant> @i<V> that is not selected by the discriminant value
+governing the @fa<variant_part> enclosing @i<V>.
+@dby
+For a @fa<record_aggregate> or @fa<extension_aggregate>, if a
+@fa<variant_part> @i<P> is nested within a @fa<variant> @i<V> that is not
+selected by the discriminant value governing the @fa<variant_part> enclosing
+@i<V>, then there is no restriction on the discriminant governing @i<P>.
+Otherwise, the value of the discriminant that governs @i<P> shall be given by
+a static expression, or by a nonstatic expression having a constrained static
+nominal subtype. In this latter case of a nonstatic expression, there shall be
+exactly one @fa<discrete_choice_list> of @i<P> that covers each value that
+belongs to the nominal subtype and satisfies the predicates of the subtype,
+and there shall be at least one such value.
+
+!corrigendum 4.3.1(17.1/2)
+
+@dinsa
+A @fa<record_component_association> for a discriminant without a
+@fa<default_expression> shall have an @fa<expression> rather than <@>.
+
+@dinss
+A @fa<record_component_association> of the @fa<record_component_association_list>
+of a @fa<record_delta_aggregate> shall not:
+
+@xbullet<use the compound delimiter <@> (box) rather than an @fa<expression>;>
+
+@xbullet<have an @fa<expression> of a limited type;>
+
+@xbullet<omit the @fa<component_choice_list>; or>
+
+@xbullet<have a @fa<component_choice_list> that is an @b<others> choice.>
+
+For a @fa<record_delta_aggregate>, no two @i<component_>@fa<selector_name>s
+shall denote components declared within different @fa<variant>s of the same
+@fa<variant_part>.
+
+!corrigendum 4.3.3(4)
+
+@drepl
+@xcode<@fa<named_array_aggregate>@fa< ::=>
+    @fa<(array_component_association {, array_component_association})>>
+@dby
+@xcode<@fa<named_array_aggregate>@fa< ::= ( array_component_association_list )>>
+
+@xcode<@fa<array_component_association_list>@fa< ::=>
+    @fa<array_component_association {, array_component_association}>>
+
+!corrigendum 4.3.3(14)
+
+@dinsa
+@xbullet<For a component @fa<expression> in an @fa<aggregate>, if the
+component's nominal subtype is a constrained array subtype, the applicable
+index constraint is the constraint of the subtype;>
+@dinst
+@xbullet<For the @i<base_>@fa<expression> of a @fa<delta_aggregate>, if the
+nominal subtype of the @fa<delta_aggregate> is a constrained array subtype,
+the applicable index constraint is the constraint of the subtype;>
+
+!corrigendum 4.3.3(17/3)
+
+@drepl
+The @fa<discrete_choice_list> of an @fa<array_component_association> is allowed to
+have a @fa<discrete_choice> that is a nonstatic @fa<choice_expression> or that is a
+@fa<subtype_indication> or @fa<range> that defines a nonstatic or null range, only
+if it is the single @fa<discrete_choice> of its @fa<discrete_choice_list>, and there
+is only one @fa<array_component_association> in the @fa<array_aggregate>.
+@dby
+The @fa<discrete_choice_list> of an @fa<array_component_association> (including
+an @fa<iterated_component_association>) is allowed to
+have a @fa<discrete_choice> that is a nonstatic @fa<choice_expression> or that is a
+@fa<subtype_indication> or @fa<range> that defines a nonstatic or null range, only
+if it is the single @fa<discrete_choice> of its @fa<discrete_choice_list>, and
+either there is only one @fa<array_component_association> in the
+enclosing @fa<array_component_association_list> or the enclosing @fa<aggregate> is
+an @fa<array_delta_aggregate>, not an @fa<array_aggregate>.
+
+!corrigendum 4.3.4(0)
+
+@dinsc
+A (record or array) delta aggregate yields a composite value resulting from
+starting with a copy of another value of the same type and then subsequently
+assigning to some (but typically not all) components of the copy.
+
+@s8<@i<Syntax>>
+
+@xcode<@fa<delta_aggregate>@fa< ::= >@fa<record_delta_aggregate> | @fa<array_delta_aggregate>>
+
+@xcode<@fa<record_delta_aggregate>@fa< ::=>
+    @fa<(@i<base_>expression >@ft<@b<with delta>>@fa< record_component_association_list)>>
+
+@xcode<@fa<array_delta_aggregate>@fa< ::=>
+    @fa<(@i<base_>expression >@ft<@b<with delta>>@fa< array_component_association_list)>>
+
+@s8<@i<Name Resolution Rules>>
+
+The expected type for a @fa<record_delta_aggregate> shall be a single
+descendant of a record type or record extension.
+
+The expected type for an @fa<array_delta_aggregate> shall be a single
+array type.
+
+The expected type for the @i<base_>@fa<expression> of any
+@fa<delta_aggregate> is the type of the enclosing @fa<delta_aggregate>.
+
+The Name Resolution Rules and Legality Rules for each
+@fa<record_component_association> of a @fa<record_delta_aggregate> are as
+defined in 4.3.1.
+
+For an @fa<array_delta_aggregate>, the expected type for each
+@fa<discrete_choice> in an @fa<array_component_association> is the index type
+of the type of the @fa<delta_aggregate>.
+
+The expected type of the @fa<expression> in
+@fa<array_component_association> is defined as for an
+@fa<array_component_association> occurring within an @fa<array_aggregate> of
+the type of the @fa<delta_aggregate>.
+
+@s8<@i<Legality Rules>>
+
+For an @fa<array_delta_aggregate>, the @fa<array_component_association> shall
+not use the box symbol <@>, and the @fa<discrete_choice> shall not be @b<others>.
+
+For an @fa<array_delta_aggregate>, the dimensionality of the type of the
+@fa<delta_aggregate> shall be 1.
+
+For an @fa<array_delta_aggregate>, the @i<base_>@fa<expression> and each
+@fa<expression> in every @fa<array_component_association> shall be of a
+nonlimited type.
+
+@s8<@i<Dynamic Semantics>>
+
+The evaluation of a @fa<delta_aggregate> begins with evaluating the
+@i<base_>@fa<expression> of the @fa<delta_aggregate> and using that value to
+create and initialize the anonymous object of the @fa<aggregate>. The bounds
+of the anonymous object of an @fa<array_delta_aggregate> and the discriminants
+and tag (if any) of the anonymous object of a @fa<record_delta_aggregate> are
+those of the @i<base_>@fa<expression>.
+
+For a @fa<record_delta_aggregate>, for each component associated with each
+@fa<record_component_association> (in an unspecified order):
+
+@xbullet<if the associated component belongs to a @fa<variant>, a check is
+  made that the values of the discriminants are such that the anonymous object
+  has this component. The exception Constraint_Error is raised if this check
+  fails.>
+
+@xbullet<the @fa<expression> of the @fa<record_component_association> is
+  evaluated, converted to the nominal subtype of the associated component,
+  and assigned to the component of the anonymous object.>
+
+For an @fa<array_delta_aggregate>, for each @fa<discrete_choice> of each
+@fa<array_component_assocation> (in the order given in the enclosing
+@fa<discrete_choice_list> and @fa<array_component_assocation_list>,
+respectively) the @fa<discrete_choice> is evaluated; for each represented
+index value (in ascending order, if the @fa<discrete_choice> represents a
+range):
+
+@xbullet<the index value is converted to the index type of the array type.>
+
+@xbullet<a check is made that the index value belongs to the index range of
+  the anonymous object of the @fa<aggregate>; Constraint_Error is raised if
+  this check fails.>
+
+@xbullet<the component @fa<expression> is evaluated, converted to the array
+  component subtype, and assigned to the component of the anonymous
+  object identified by the index value.>
+
+@s8<@i<Examples>>
+
+Simple use in a postcondition:
+
+@xcode<@b<procedure> Twelfth (D : @b<in out> Date) --@ft<@i< see 3.8 for type Date>>
+   @b<with> Post =@> D = (D'Old @b<with delta> Day =@> 12);>
+
+@xcode<@b<procedure> The_Answer (V : @b<in out> Vector; A, B : @b<in> Integer) --@ft<@i< see 3.6 for type Vector>>
+   @b<with> Post =@> V = (V'Old @b<with delta> A .. B =@> 42.0, V'First =@> 0.0);>
+
+The base expression can be non-trivial:
+
+@xcode<New_Cell : Cell := (Min_Cell (Link) @b<with delta> Value =@> 42);
+   --@ft<@i< see 3.10.1 for Cell and Link; 6.1 for Min_Cell>>>
+
+@xcode<A1 : Vector := ((1.0, 2.0, 3.0) @b<with delta> Integer (Random * 3.0) =@> 14.2);
+   --@ft<@i< see 3.6 for declaration of type Vector>>
+   --@ft<@i< see 6.1 for declaration of Random>>>
+
+@xcode<Tomorrow := ((Yesterday @b<with delta> Day =@> 12) @b<with delta> Month =@> Apr); --@ft<@i< see 3.8>>>
+
+The base expression may also be class-wide:
+
+@xcode<@b<function> Translate (P : Point'Class; X, Y : Float) @b<return> Point'Class @b<is>
+   (P @b<with delta> X =@> P.X + X,
+                 Y =@> P.Y + Y); --@ft<@i< see 3.9 for declaration of type Point>>>
+
+!corrigendum 7.5(2.6/2)
+
+@dinsa
+@xbullet<an @fa<expression> of a @fa<positional_array_aggregate> or the
+@fa<expression> of an array_component_association (see 4.3.3)>
+@dinst
+@xbullet<the @i<base_>@fa<expression> of a @fa<record_delta_aggregate>
+(see 4.3.4)>
+
 !ASIS
 
 No ASIS impact.
@@ -466,7 +808,7 @@
 
 ****************************************************************
 
-From: Tucker Taft
+From: Randy Brukardt
 Sent: Tuesday, July 15, 2014   5:46 PM
 
 Steve Baird had told me about this attribute in Paris. One thing almost everyone
@@ -852,9 +1194,9 @@
 From: Bob Duff
 Sent: Monday, June 6, 2016  12:14 PM
 
-> A (record, array, multidimensional) delta aggregate yields a composite 
-> value resulting from copying another value of the same type and then 
-> subsequently assigning to some (but typically not all) components of 
+> A (record, array, multidimensional) delta aggregate yields a composite
+> value resulting from copying another value of the same type and then
+> subsequently assigning to some (but typically not all) components of
 > the copy.
 
 I like this feature.  I don't much like the keyword "delta"; seems contrived.
@@ -877,24 +1219,24 @@
     index_tuple ::= ( expression, expression {, expression} )
 
 > ** Name Resolution Rules **
-> 
-> The type of a delta aggregate is the same as the type of the 
+>
+> The type of a delta aggregate is the same as the type of the
 > expression in delta_aggregate.
 
 I think you want the type to come from context, like other aggregates.
 Then that type becomes the expected type for the expression.
 
-> For an array delta aggregate, the dimensionality of the type of the 
-> delta aggregate shall be 1; for a multidimensional delta aggregate the 
+> For an array delta aggregate, the dimensionality of the type of the
+> delta aggregate shall be 1; for a multidimensional delta aggregate the
 > dimensionality of the type of the delta aggregate shall more than 1.
 
 Here's a place where the above-mentioned ambiguity comes into play.
 
 > Ranges in multidimensional updates
 > ----------------------------------
-> 
-> This is a proposal to allow more helpful (but slightly more complex) 
-> multidimensional delta aggregates. It is presented as a modification 
+>
+> This is a proposal to allow more helpful (but slightly more complex)
+> multidimensional delta aggregates. It is presented as a modification
 > to the above !wording section.
 
 I'd leave this functionality out.
@@ -904,8 +1246,8 @@
 From: Randy Brukardt
 Sent: Monday, June 6, 2016  11:42 PM
 
-> This AI is part of my (overdue) Pisa homework. I have worked 
-> on this with the help of Steve. It should be concrete enough 
+> This AI is part of my (overdue) Pisa homework. I have worked
+> on this with the help of Steve. It should be concrete enough
 > so that we have something to discuss.
 
 I suppose we should know better than to pair the new guy with Steve; Steve
@@ -923,9 +1265,9 @@
 From: Steve Baird
 Sent: Tuesday, June 7, 2016  2:32 AM
 
->> For an array delta aggregate, the dimensionality of the type of the 
+>> For an array delta aggregate, the dimensionality of the type of the
 >> delta
->> >aggregate shall be 1; for a multidimensional delta aggregate the 
+>> >aggregate shall be 1; for a multidimensional delta aggregate the
 >> >dimensionality of the type of the delta aggregate shall more than 1.
 > Here's a place where the above-mentioned ambiguity comes into play.
 >
@@ -964,7 +1306,7 @@
 closely as possible):
 
    The expected type for a delta_aggregate shall be a single array type, record
-   type, or record extension. The expected type for the *base_*expression 
+   type, or record extension. The expected type for the *base_*expression
    is the type of the enclosing delta_aggregate.
 
 Note that I gave the first expression in the aggregate a prefix so it can't be
@@ -1008,11 +1350,11 @@
 
 ...
 > The next paragraph doesn't make any sense as written:
-> 
-> The expected type for expression in a delta_aggregate depends on which 
-> form of delta_aggregate_association is used: a record type for 
-> record_component_association_list, and an array type for 
-> array_component_association_list or 
+>
+> The expected type for expression in a delta_aggregate depends on which
+> form of delta_aggregate_association is used: a record type for
+> record_component_association_list, and an array type for
+> array_component_association_list or
 > multidimensional_array_component_association_list.
 
 It strikes me that there needs to be a Legality Rule that prevents a record
@@ -1035,31 +1377,31 @@
 From: Bob Duff
 Sent: Tuesday, June 7, 2016  6:03 PM
 
-> >> For an array delta aggregate, the dimensionality of the type of the 
+> >> For an array delta aggregate, the dimensionality of the type of the
 > >> delta
-> >> >aggregate shall be 1; for a multidimensional delta aggregate the 
+> >> >aggregate shall be 1; for a multidimensional delta aggregate the
 > >> >dimensionality of the type of the delta aggregate shall more than 1.
 > > Here's a place where the above-mentioned ambiguity comes into play.
 > >
-> 
+>
 > I'd say that's the place where the ambiguity is resolved.
 
 No, that's not marked as a Name Resolution rule.  Just Legality.
 So it can't be used to resolve syntactic ambiguities.
 
-> But I agree that your proposed syntax change is an improvement and 
+> But I agree that your proposed syntax change is an improvement and
 > with that change there is no ambiguity to even discuss.
 
 OK.
 
 > > I think you want the type to come from context, like other aggregates.
 > > Then that type becomes the expected type for the expression.
-> 
-> Interesting question. Given that we didn't modify 4.3(3/2), I agree 
+>
+> Interesting question. Given that we didn't modify 4.3(3/2), I agree
 > with you. But we could modify that rule.
-> 
+>
 > Do we want to allow
-> 
+>
 >       type T is new String;
 >       procedure P (X : String) is ... ;
 >       procedure P (X : T) is ... ;
@@ -1069,7 +1411,7 @@
 
 No.  Resolution rules should be weak.
 
-> ? Probably not, so 4.3(3/2) is left unmodified and I agree with your 
+> ? Probably not, so 4.3(3/2) is left unmodified and I agree with your
 > proposed change.
 
 ****************************************************************
@@ -1077,7 +1419,7 @@
 From: Steve Baird
 Sent: Wednesday, June 8, 2016  5:58 AM
 
-> It strikes me that there needs to be a Legality Rule that prevents a 
+> It strikes me that there needs to be a Legality Rule that prevents a
 > record from having array components and vice versa
 
 We already have name resolution rules like
@@ -1112,10 +1454,10 @@
 From: Bob Duff
 Sent: Wednesday, June 8, 2016  6:05 AM
 
-> Would it be more consistent to have name resolution rules (as opposed 
-> to legality rules) which specify that the expected type of a 
-> delta_aggregate is a single record type or record extension if the 
-> delta_aggregate_association is a record_component_association_list and 
+> Would it be more consistent to have name resolution rules (as opposed
+> to legality rules) which specify that the expected type of a
+> delta_aggregate is a single record type or record extension if the
+> delta_aggregate_association is a record_component_association_list and
 > a single array type otherwise ?
 
 Maybe have separate syntax rules for delta_record_aggregate and
@@ -1177,19 +1519,19 @@
 From: Tucker Taft
 Sent: Thursday, September 29, 2016  4:57 PM
 
-> I haven't read Florian's write up yet, but discrete range choices and 
-> the like of aggregates are modeled as a loop in the language semantics 
-> -- the component value is evaluated and assigned for each value of the 
+> I haven't read Florian's write up yet, but discrete range choices and
+> the like of aggregates are modeled as a loop in the language semantics
+> -- the component value is evaluated and assigned for each value of the
 > range (in an unspecified order).
 >
-> I would have expected Florian's write-up to keep the semantics of each 
+> I would have expected Florian's write-up to keep the semantics of each
 > kind of choice the same, so that there is as little new complication as possible.
-> (I'm sure he doesn't want to redescribe the various kinds of array 
+> (I'm sure he doesn't want to redescribe the various kinds of array
 > choices and their semantics.)
 >
-> Ergo, there are no "slice assignments"; it's just a bunch of 
-> individual components being updated. That's important for wording 
-> purposes (whether one wants to think of it as a slice assignment is 
+> Ergo, there are no "slice assignments"; it's just a bunch of
+> individual components being updated. That's important for wording
+> purposes (whether one wants to think of it as a slice assignment is
 > your own option, of course, but the language certainly would not consider it so).
 
 I agree with the above.
@@ -1198,7 +1540,7 @@
 >     (A delta 1..3 => Foo)
 > and (A delta 1 => Foo, 2 => Foo, 3 => Foo)
 >
-> have exactly the same canonical semantics, and there is no slice 
+> have exactly the same canonical semantics, and there is no slice
 > anywhere to be seen.
 
 Agreed.  But I also haven't gone through the proposed wording in detail yet!
@@ -1211,10 +1553,10 @@
 > Specifically:
 >    (A delta 1..3 => Foo)
 > and (A delta 1 => Foo, 2 => Foo, 3 => Foo)
-> 
-> have exactly the same canonical semantics, and there is no slice 
+>
+> have exactly the same canonical semantics, and there is no slice
 > anywhere to be seen.
-> 
+>
 
 Makes sense, and indeed the code will have to consist of individual
 assignments.
@@ -1242,9 +1584,9 @@
 Sent: Sunday, October 2, 2016  11:48 PM
 
 > ... But expecting the
-> reader, as an aid to understanding the dynamic semantics of delta 
-> aggregates, to have to look forward to the definition of 'Old, 
-> followed by a perusal of the build-in-place rules, seems downright 
+> reader, as an aid to understanding the dynamic semantics of delta
+> aggregates, to have to look forward to the definition of 'Old,
+> followed by a perusal of the build-in-place rules, seems downright
 > perverse! ;-)
 
 I recognize the Hand of Baird in this text! ;-) Steve was originally a
@@ -1255,9 +1597,9 @@
 From: Randy Brukardt
 Sent: Sunday, October 2, 2016  11:24 PM
 
-> This is my attempt at implementing everything that was discussed and 
-> recorded in the minutes (btw, thanks Randy for these, they are 
-> excellent!). I have also attached a patch for the text file version. 
+> This is my attempt at implementing everything that was discussed and
+> recorded in the minutes (btw, thanks Randy for these, they are
+> excellent!). I have also attached a patch for the text file version.
 > This may be more convenient for you to apply. YMMV.
 
 One thing that was suggested in e-mail [by Bob, I think] (not the minutes)
@@ -1279,7 +1621,7 @@
 
   record_delta_aggregate ::= (*base_*expression with delta
                               record_component_association_list)
- 
+
   array_delta_aggregate ::= (*base_*expression with delta
                               array_component_association_list)
 
@@ -1325,7 +1667,7 @@
 
 ---
 
-I second Tucker's comment about 'Old. I can't imagine what that has to do with 
+I second Tucker's comment about 'Old. I can't imagine what that has to do with
 aggregate semantics; it would make more sense if 'Old had been described in
 terms of delta aggregate semantics.  I think that whatever semantics needs to
 be described normatively, needs to be described here, and the rest can go into
@@ -1344,14 +1686,14 @@
 From: Randy Brukardt
 Sent: Sunday, October 2, 2016  11:35 PM
 
-Two other comments: 
+Two other comments:
 
-> For a delta aggregate the expression in a record_component_association 
+> For a delta aggregate the expression in a record_component_association
 > or a array_component_association shall not be of a limited type.
-> 
-> Which expression is being discussed here? I'd guess that it is 
-> supposed to be the *base*_expression, and if that's the intent, this 
-> rule should say that. (Use the prefix if you go through the trouble to 
+>
+> Which expression is being discussed here? I'd guess that it is
+> supposed to be the *base*_expression, and if that's the intent, this
+> rule should say that. (Use the prefix if you go through the trouble to
 > define it!) [P.S. I took the extra comma out of  your version.]
 
 The rule added after 7.5(2.10/2) has the same issue.
@@ -1379,14 +1721,14 @@
 From: Florian Schanda
 Sent: Tuesday, October 4, 2016  5:13 AM
 
-> PLEASE do not get in the habit of just updating the wording and 
-> leaving the rest of it to the poor editor. The wording is often the 
-> easy part! And I am not good at guessing what your intent is (which is 
+> PLEASE do not get in the habit of just updating the wording and
+> leaving the rest of it to the poor editor. The wording is often the
+> easy part! And I am not good at guessing what your intent is (which is
 > what goes in the discussion). I'll fix up headers and file e-mail, but
 > that's it.
 
 Oh, right. I think I suffered from a mis-understanding then. I was imagining
-I was told off before for changing the rest; so if its OK to change the bit 
+I was told off before for changing the rest; so if its OK to change the bit
 before the wording then I shall do that!
 
 I do want to be a good citizen :)
@@ -1396,8 +1738,8 @@
 From: Randy Brukardt
 Sent: Wednesday, October 5, 2016  9:24 PM
 
-> Oh, right. I think I suffered from a mis-understanding then. 
-> I was imagining I was told off before for changing the rest; so if its 
+> Oh, right. I think I suffered from a mis-understanding then.
+> I was imagining I was told off before for changing the rest; so if its
 > OK to change the bit before the wording then I shall do that!
 
 Well, the !question (or !problem) should generally be left alone unless you
@@ -1417,14 +1759,14 @@
 From: Florian Schanda
 Sent: Tuesday, October 4, 2016  9:14 AM
 
-> But... I worry that we are referencing the semantics of 'Old and 
-> build-in-place in the  dynamic semantics section.  I could see 
-> mentioning them in an AARM note.  But expecting the reader, as an aid 
-> to understanding the dynamic semantics of delta aggregates, to have to 
-> look forward to the definition of 'Old, followed by a perusal of the 
-> build-in-place rules, seems downright perverse! ;-)  You have these 
-> references in brackets, so I presume that means this is redundant 
-> information and hence not necessary to appear in normative RM text 
+> But... I worry that we are referencing the semantics of 'Old and
+> build-in-place in the  dynamic semantics section.  I could see
+> mentioning them in an AARM note.  But expecting the reader, as an aid
+> to understanding the dynamic semantics of delta aggregates, to have to
+> look forward to the definition of 'Old, followed by a perusal of the
+> build-in-place rules, seems downright perverse! ;-)  You have these
+> references in brackets, so I presume that means this is redundant
+> information and hence not necessary to appear in normative RM text
 > here. If so, I heartily suggest that the bracketed wording move to an AARM
 > note.
 
@@ -1436,12 +1778,12 @@
 From: Florian Schanda
 Sent: Tuesday, October 4, 2016  9:20 AM
 
-> For a delta aggregate the expression in a record_component_association 
+> For a delta aggregate the expression in a record_component_association
 > or a array_component_association shall not be of a limited type.
-> 
-> Which expression is being discussed here? I'd guess that it is 
-> supposed to be the *base*_expression, and if that's the intent, this 
-> rule should say that. (Use the prefix if you go through the trouble to 
+>
+> Which expression is being discussed here? I'd guess that it is
+> supposed to be the *base*_expression, and if that's the intent, this
+> rule should say that. (Use the prefix if you go through the trouble to
 > define it!) [P.S. I took the extra comma out of  your version.]
 
 No, it really does mean the expression in each
@@ -1456,11 +1798,11 @@
 From: Florian Schanda
 Sent: Tuesday, October 4, 2016  9:21 AM
 
-> In the examples, you need cross-references to where the objects/types 
-> are declared elsewhere in the RM. For instance, the first example 
-> should have something like "(See x.x.x for the declaration of D.)" as 
-> part of the comment. I'm not going to try to figure out where an 
-> object named "D" is declared in the RM! (Searching doesn't work for 
+> In the examples, you need cross-references to where the objects/types
+> are declared elsewhere in the RM. For instance, the first example
+> should have something like "(See x.x.x for the declaration of D.)" as
+> part of the comment. I'm not going to try to figure out where an
+> object named "D" is declared in the RM! (Searching doesn't work for
 > obvious reasons.)
 
 Ok, I've done this. I'll send an updated version tomorrow that will
@@ -1483,7 +1825,7 @@
 
 A few minor points.
 
-> A (record, array) delta aggregate yields a composite value resulting 
+> A (record, array) delta aggregate yields a composite value resulting
 > from copying another value of the same type
 
 This is informal introductory text, so I'd suggest replacing "copying"
@@ -1491,18 +1833,18 @@
 We don't want to suggest that we are copying limited values.
 
 >
-> The expected type for a record_delta_aggregate shall be a record type, 
+> The expected type for a record_delta_aggregate shall be a record type,
 > or record extension.
 >
-> The expected type for an array_delta_aggregate shall be a single array 
+> The expected type for an array_delta_aggregate shall be a single array
 > type.
 
 Why is the word "single" missing in the record case?
 Note that the analogous rule in 4.3.1 says "shall be a single record type
 or record extension".
 
-> For an array_delta_aggregates, the expected type for each 
-> discrete_choice in an array_component_association is the index type of 
+> For an array_delta_aggregates, the expected type for each
+> discrete_choice in an array_component_association is the index type of
 > type of the delta aggregate.
 
 Only a language lawyer would care about this one, but ...
@@ -1521,11 +1863,11 @@
 From: Randy Brukardt
 Sent: Wednesday, October 5, 2016  7:41 PM
 
-> > A (record, array) delta aggregate yields a composite value resulting 
+> > A (record, array) delta aggregate yields a composite value resulting
 > > from copying another value of the same type
-> 
-> This is informal introductory text, so I'd suggest replacing "copying" 
-> with "starting with" because the type of the aggregate can be limited. 
+>
+> This is informal introductory text, so I'd suggest replacing "copying"
+> with "starting with" because the type of the aggregate can be limited.
 > We don't want to suggest that we are copying limited values.
 
 Right. I've made an updated version of the AI with the first two of Steve's
@@ -1547,9 +1889,9 @@
 (you would not be able to update anything).
 
 It took me a while to figure this out. I believe the point is that it isn't
-possible to have declared limited array with non-limited components. [I suspect
-that this idea is incorrect in bizarre corner cases, but it probably isn't
-worth having support for this that only useful in pathological cases.]
+possible to have declared a limited array with non-limited components. [I
+suspect that this idea is incorrect in bizarre corner cases, but it probably
+isn't worth having support for this that only useful in pathological cases.]
 
 However, if we're not going to allow limited *base*_expressions for an
 array_delta_aggregate, then we need a Legality Rule to that effect in 4.3.4.
@@ -1558,27 +1900,27 @@
 
 [I made these changes in my update.]
 
-> > The expected type for a record_delta_aggregate shall be a record 
+> > The expected type for a record_delta_aggregate shall be a record
 > > type, or record extension.
 > >
-> > The expected type for an array_delta_aggregate shall be a single 
+> > The expected type for an array_delta_aggregate shall be a single
 > > array type.
-> 
+>
 > Why is the word "single" missing in the record case?
-> Note that the analogous rule in 4.3.1 says "shall be a single record 
+> Note that the analogous rule in 4.3.1 says "shall be a single record
 > type or record extension".
 
 Looks like a mistake to me; there's also an extra comma. I made those changes
 in my update.
 
-> > For an array_delta_aggregates, the expected type for each 
-> > discrete_choice in an array_component_association is the index type 
+> > For an array_delta_aggregates, the expected type for each
+> > discrete_choice in an array_component_association is the index type
 > > of type of the delta aggregate.
-> 
+>
 > Only a language lawyer would care about this one, but ...
-> 
+>
 > A name resolution rule shouldn't depend on a legality rule.
-> So strictly speaking this should really say something like "the first 
+> So strictly speaking this should really say something like "the first
 > index type" even though
 >     a) later on a legality rule will impose a requirement that that
 >        the array type's dimensionality is 1; and
@@ -1715,12 +2057,12 @@
 From: Simon Wright
 Sent: Wednesday, August 9, 2017  10:26 AM
 
-> The record Rec of this example seems to have among others the two 
+> The record Rec of this example seems to have among others the two
 > components Color and Shape. Thus the Post condition seems to return False:
-> 
+>
 >   procedure Foo (Fighters : in out Rec)
 >      with Post => (Fighters.Colour = Black and
->                    Fighters = (Fighters'Old with delta Shape => 
+>                    Fighters = (Fighters'Old with delta Shape =>
 > Trapazoid));
 
 Spello: TrapEzoid
@@ -1731,13 +2073,13 @@
 Sent: Wednesday, August 9, 2017  11:56 AM
 
 > Shouldn't this be
-> 
+>
 >    procedure Foo (Fighters : in out Rec)
 >       with Post => (Fighters = (Fighters'Old with delta
 >                                   Shape  => Trapazoid,
 >                                   Colour => Black));
-> 
-> (This example is not part of the examples of the wording section, so 
+>
+> (This example is not part of the examples of the wording section, so
 > the error is not overly fatal, because it won't go into the RM.)
 
 Sounds right to me.
@@ -1752,7 +2094,7 @@
 > I just read ai12-0127 (at
 > http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai12s/ai12-0127-1.t
 > xt?rev=1.10)
-> (with an eye towards enhancing Emacs Ada mode to support the new 
+> (with an eye towards enhancing Emacs Ada mode to support the new
 > syntax), and I noticed a few typos:
 ...
 
@@ -1851,7 +2193,7 @@
 
 This is an important AI that it would be good to progress.
 
-> All I found was the following, presented in the usual grocery-list 
+> All I found was the following, presented in the usual grocery-list
 > normal form.
 
 I could deal with the first three, but the fourth is just a complaint without
@@ -1881,7 +2223,7 @@
 
 ..
 > I happened to notice that the last update to this AI (sent by
-> Florian) happened exactly a year ago, although the current date on the 
+> Florian) happened exactly a year ago, although the current date on the
 > AI is shown as Oct. 6, 2016.
 
 I did notice that the AI was almost exactly a year old when replying to Steve,
@@ -1936,27 +2278,27 @@
 Sent: Saturday, October 14, 2017  7:15 AM
 
 > Replace
->  The expected type for a record_delta_aggregate shall be a single  
+>  The expected type for a record_delta_aggregate shall be a single
 > record type or record extension.
-> 
+>
 > with
-> 
+>
 >   The expected type for a record_delta_aggregate shall be a single
 >   descendant of a record type.
 
 Why can't it be a single descendant of a record type or a tagged private type?
- 
+
 > =====
-> 
+>
 > After
-> 
->  For a record_delta_aggregate, each component_selector_name of each  
-> component_choice_list shall denote a distinct non discriminant  
+>
+>  For a record_delta_aggregate, each component_selector_name of each
+> component_choice_list shall denote a distinct non discriminant
 > component of the type of the delta aggregate.
-> 
+>
 > Add
-> 
->  No two such component_selectors shall denote components declared  
+>
+>  No two such component_selectors shall denote components declared
 > within different variants of the same variant part.
 
 Sounds good.
@@ -2075,6 +2417,696 @@
    record type or of a record_extension.
 
    The type of an array_delta_aggregate shall be an array type.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, December  1, 2017  12:38 AM
+
+My understanding is that we don't want positional delta aggregates. However,
+I don't see any rule in AI12-0127-1 that requires a component_selector_name
+or a component_choice_list for a record aggregate. (The syntax requires this
+for an array_delta_aggregate, so no rule is needed for the array case.)
+
+The AI should have spelled this out in the discussion (that is, that all
+components have to be named), but it doesn't. Nor is there any idea how to
+figure what component is "first" if the names are omitted. The fact that
+arrays require named components suggest that records were intended to do so
+as well, but since the topic isn't discussed, it's hard to be certain.
+
+Anyway, there are number of rules about the contents of selector_names and
+choice_lists, but these are of the same form as the similar rules for record
+aggregates. So one has to read these with an implied "if present" (since
+record aggregates surely do allow positional aggregates).
+
+So I think we need to say something like:
+
+For a record_delta_aggregate, each record_component_association shall include
+a component_choice_list.
+
+We probably can combine this with one of the existing rules; the first
+Legality Rule seems best:
+
+   For a record_delta_aggregate, a record_component_association_list
+   shall not be null record. A record_component_association of the
+   record_component_association_list of a record_delta_aggregate
+   shall not use the box symbol <>, it shall include a component_choice_list,
+   and that component_choice_list shall not include an others choice.
+
+[I reworded the last part a bit to better fit with the rest.]
+
+Thoughts? Brickbats?
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, December  1, 2017  1:30 PM
+
+Since there isn't anything in the AI or the minutes about only allowing named
+notation, I fear that this AI will have to go back for another vote unless we
+can have a clear consensus here in e-mail. So far, that seems to just mean me,
+which isn't enough. :-) So please comment ASAP.
+
+****************************************************************
+
+From: Jeff Cousins
+Sent: Friday, December  1, 2017  1:55 PM
+
+You sound correct to me, I was going to re-read the AI tomorrow. The
+positional form should be discouraged anyway.
+
+****************************************************************
+
+From: Ed Schonberg
+Sent: Friday, December  1, 2017  2:05 PM
+
+Positional notation, or an “others” association make no sense for a delta,
+your new formulation is fine. The current implementation of the AI in GNAT
+only accepts named associations, it never occurred to me to handle anything
+else.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Friday, December  1, 2017  2:09 PM
+
+> Since there isn't anything in the AI or the minutes about only
+> allowing named notation, I fear that this AI will have to go back for
+> another vote unless we can have a clear consensus here in e-mail. So
+> far, that seems to just mean me, which isn't enough. :-) So please comment
+> ASAP.
+
+I agree with you.  But why don't you call for a letter ballot?
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, December  1, 2017  2:24 PM
+
+Happy to limit delta aggregates to fully named notation.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, December  1, 2017  3:06 PM
+
+> I agree with you.  But why don't you call for a letter ballot?
+
+I mostly was interested in what to put into the draft RM, since I was about
+80% finished with that when I ran into this issue last night. Too late to
+undo that work, so I need a preliminary answer in the next couple of working
+days. For a formal answer, the January phone call is soon enough (a Letter
+Ballot would take most of that time).
+
+And of course the real reason -- I didn't think of using a Letter Ballot. :-)
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, December  1, 2017  7:08 PM
+
+...on top of the several pages of typos and editorials (to be sent when I'm
+finished with this AI).
+
+The minutes have the following (other than the note in brackets):
+
+... just replace 4.3(3): [Which, BTW, is really 4.3(3/2) - RLB]
+
+   The expected type for a delta_aggregate shall be a single array type,
+   or a single descendant of a record type or of a record extension. The
+   expected type for any other aggregate shall be a single array type,
+   record type, or record extension.
+
+For 4.3.4, use the following for the resolution rules:
+
+   The expected type for a record_delta_aggregate shall be a single
+   record type or record extension.
+
+   The expected type for an array_delta_aggregate shall be a single
+   array type.
+
+But this latter record rule doesn't allow private types with visible record
+type/extension ancestors, which was the entire point of the change. Most
+likely, the rule should match the 4.3(3/2) wording...
+
+   The expected type for a record_delta_aggregate shall be a single
+   descendant of a record type or record extension.
+
+We're reaching the point of too many changes. I think I agree with Bob that we
+ought to have a Letter Ballot, so we don't have to waste our limited time on
+this during our call. (There are at least two other AIs that can be handled on
+the same ballot.)
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, December  1, 2017  9:23 PM
+
+(Actually, this has turned into a complete rabbit hole. Probably most of you
+should jump to the bottom and just read the conclusions...but not Steve, he
+was the one that was supposed to work this out and obviously botched it. :-)
+
+The third last paragraph of the Name Resolution Rules in 4.3.4 says:
+
+  For a record_delta_aggregate, the expected type and applicable index
+  constraint of the expression in each record_component_association is
+  defined as for a record_component_association occurring within a
+  record_aggregate.
+
+The last paragraph of the Name Resolution Rules in 4.3.4 says:
+
+  The expected type and applicable index constraint of the expression in
+  array_component_association is defined as for an
+  array_component_association occurring within an array_aggregate of the
+  type of the delta_aggregate.
+
+Why does the second of these say "of the type of the delta_aggregate" and the
+first doesn't? It would seem that if either of them needs to mention the type,
+they both would.
+
+This quickly turns into a trip into the rabbit hole.
+
+(1) There exist types which a record_aggregate would not be legal (for
+    instance, a private type descended from a record type), so we don't want
+    to insist on the type.
+
+(2) There is no reason that I can see to mention the applicable index type in
+    this rule; 4.3.3(14) is the applicable array aggregate rule and I can see
+    no reason why it wouldn't apply. (It just talks about component
+    expressions and aggregates, both of which clearly apply to delta
+    aggregates.) So long as the subtype is well-defined (and it has to be if
+    any of these rules work for record aggregates), we're good.
+
+(3) The actual rule that this is trying to reference (4.3.1(10) and
+    4.3.1(12)) doesn't actually mention any types. Moreover, it doesn't
+    mention any kinds of enclosing aggregate. Ergo, it already applies (there
+    is nothing that would prevent it from applying), and thus the
+    record_aggregate rule in 4.3.4 is redundant and confusing. There's a
+    similar rule in the Legality Rules. I suspect it would be better to simply
+    put a redundant statement somewhere and drop both of those rules from
+    4.3.4.
+
+Something like:
+
+    @Redundant[The interpretation of each record_component_association of a
+    record_delta_aggregate is defined in 4.3.1.]
+
+Perhaps it would be better to spell out that we mean just Name Resolution and
+Legality Rules:
+
+    @Redundant[The Name Resolution Rules and Legality Rules for each
+    record_component_association of a record_delta_aggregate are as defined in
+    4.3.1.]
+
+And we then have to fix up any rules in 4.3.1 that don't make sense.
+Unfortunately, that seems to be a bunch of them.
+
+(4) The new rule in 4.3.1 (4.3.1(9.1/5)) says:
+
+    Each selector_name in a record_component_association of a
+    record_delta_aggregate shall denote a nondiscriminant component of the
+    record type.
+
+*the record type*!!!??? What if the delta aggregate has a private extension
+type, or a record extension type?? There might not be any record type anywhere.
+(Note that we separately mention "record extension" in the record resolution
+rules.) It also doesn't say what entity the type is from. Probably this should
+just say "type of the aggregate" and quit:
+
+    Each selector_name in a record_component_association of a
+    record_delta_aggregate (see 4.3.4) shall denote a nondiscriminant component
+    of the type of the aggregate.
+
+[BTW, this probably shouldn't be a separate paragraph, either. The
+interpretation of a selector_name should be all in one paragraph. Also, as this
+is a forward reference, we probably ought to mention where
+record_delta_aggregate can be found (as I did above). For the HTML version, one
+can just click on it to go there, but a paper or PDF version isn't so easy to
+figure out. Finally, I don't know why the *component_* part is omitted in this
+paragraph; it seems to be in most of the other rules. Best to add it in.]
+
+(5) Turning to the Legality Rules, 4.3.1(14) isn't about component associations.
+4.3.1(17.1/2) seems OK, and <> isn't allowed anyway (another separate Legality
+Rule).
+
+4.3.1(16/4) seems to have a problem however:
+
+Each record_component_association other than an others choice with a <> shall
+have at least one associated component, and each needed component shall be
+associated with exactly one record_component_association. If a
+record_component_association with an expression has two or more associated
+components, all of them shall be of the same type, or all of them shall be of
+anonymous access types whose subtypes statically match. In addition, Legality
+Rules are enforced separately for each associated component.
+
+The problem here is ", and each needed component shall be associated with
+exactly one record_component_association". We didn't define "needed" for delta
+aggregates, so this part of the rule is impossible to interpret. Probably we
+need to bifurcate this like we did with 4.3.1(9/5) (which would move one of the
+rules found in 4.3.4 here - avoid duplication!). The last two sentences do need
+to apply here. This gives something like as a replacement for 4.3.1(16/4):
+
+For a record_delta_aggregate, each component_selector_name of each
+component_choice_list shall denote a distinct nondiscriminant component of the
+type of the aggregate. For other aggregates, each record_component_association
+other than an others choice with a <> shall have at least one associated
+component, and each needed component shall be associated with exactly one
+record_component_association.
+
+If a record_component_association with an expression has two or more associated
+components, all of them shall be of the same type, or all of them shall be of
+anonymous access types whose subtypes statically match. In addition, Legality
+Rules are enforced separately for each associated component.
+
+[Note: I split this into two paragraphs, so it's clearer that the second part
+applies to all aggregates. Otherwise it appears to only apply to the non-delta
+aggregates. Also note that this puts the less common case first, which has
+sometimes given people heartburn. It could be turned around at the cost of more
+words.]
+
+(6) It also makes more sense to bifurcate 4.3.1(15/3) as:
+
+For a record_delta_aggregate, the record_component_association_list shall not be /null record/; otherwise; the reserved words /null record/ may appear only if there are no components needed in a given record_component_association_list.
+
+Again, this avoids any issues of what "needed" means for a delta aggregate.
+Rewording the last part to be more consistent (and avoid the nasty word
+"may"):
+
+For a record_delta_aggregate, the record_component_association_list shall not be
+/null record/; otherwise, a record_component_association list shall be /null
+record/ only if there are no components needed for that list.
+
+[Note: This puts the less common case first; if that gives people serious
+heartburn we could say "For a record_aggregate or extension_aggregate" instead
+(but that's quite a bit longer).]
+
+(7) Having done that, it seems to me to make the most sense to move the renaming
+record_component_association rules to 4.3.1 as well:
+
+     A record_component_association of the
+     record_component_association_list of a record_delta_aggregate
+     shall not use the box symbol <>, it shall include a component_choice_list,
+     and that component_choice_list shall not include an others choice.
+
+     For a record_delta_aggregate, no two component_selector_names shall
+     denote components declared within different variants of the same
+     variant part.
+
+"box symbol <>" is bizarre. The only normative wording using this uses "compound
+delimiter <>" (2.2, 3.6), with a parenthetical remark about the name box in 3.6.
+So I'd replace "box symbol <>" by "compound delimiter <> (box)" here.
+
+===================================
+
+Conclusion:
+
+Move all of the record_component_association_list Resolution and Legality rules
+to 4.3.1, leaving only a cross-reference statement. Redo the rules in 4.3.1 so
+it is crystal-clear when they apply to a delta aggregate (and when they don't).
+
+Specifically:
+
+In 4.3.4 (the new delta aggregate clause), delete all of the rules about
+record_component_associations. Replace those by a single line:
+
+   @Redundant[The Name Resolution Rules and Legality Rules for each
+   record_component_association of a record_delta_aggregate are as defined in
+   4.3.1.]
+
+Replace the modified 4.3.1(9/5) and the newly inserted paragraph with:
+
+For the record_component_association_list of a record_aggregate, all components
+of the composite value defined by the aggregate are needed; for the association
+list of an extension_aggregate, only those components not determined by the
+ancestor expression or subtype are needed (see 4.3.2). Each
+*component_*selector_name in a record_component_association of a
+record_aggregate or extension_aggregate shall denote a needed component
+(including possibly a discriminant). Each *component_*selector_name in a
+record_component_association of a record_delta_aggregate (see 4.3.4) shall
+denote a nondiscriminant component of the type of the aggregate.
+
+Replace 4.3.1(15/3) with:
+
+For a record_delta_aggregate, the record_component_association_list shall not be
+/null record/; otherwise, a record_component_association list shall be /null
+record/ only if there are no components needed for that list.
+
+Replace 4.3.1(16/4) with (2 paragraphs):
+
+For a record_delta_aggregate, each component_selector_name of each
+component_choice_list shall denote a distinct nondiscriminant component of the
+type of the aggregate. For other aggregates, each record_component_association
+other than an others choice with a <> shall have at least one associated
+component, and each needed component shall be associated with exactly one
+record_component_association.
+
+[Note: One could put the usual case first by replacing "other aggregates"
+with "a record_aggregate or extension_aggregate", then swapping the lines.
+Better? I don't see an easy way to do that for 4.3.1(15/3), though.]
+
+If a record_component_association with an expression has two or more associated
+components, all of them shall be of the same type, or all of them shall be of
+anonymous access types whose subtypes statically match. In addition, Legality
+Rules are enforced separately for each associated component.
+
+Add after 4.3.1(17.1/2):
+
+     A record_component_association of the record_component_association_list
+     of a record_delta_aggregate shall not use the compound delimiter <> (box),
+     it shall include a component_choice_list, and that component_choice_list
+     shall not include an /others/ choice.
+
+     For a record_delta_aggragate, no two component_selector_names shall
+     denote components declared within different variants of the same
+     variant part.
+
+-----------------
+
+Whew! Thoughts??? (Note: I haven't looked at the array rules yet; I worry that
+they have similar issues. The record ones took all night and I still need to do
+backups...so next week.)
+
+****************************************************************
+
+From: Jeff Cousins
+Sent: Saturday, December  2, 2017  5:19 AM
+
+I would prefer to put the more usual case first in the 4.3.1(16/4) replacement.
+
+Couldn't 4.3.1(15/3) be something like:
+
+A record_component_association_list may only be a null record if no components
+are needed for that list, and the list is not for a record_delta_aggregate.
+
+or is that too simplistic?
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, December  4, 2017  6:29 PM
+
+> I would prefer to put the more usual case first in the 4.3.1(16/4)
+replacement.
+
+Seems OK assuming some change to the latter.
+
+>Couldn't 4.3.1(15/3) be something like:
+>
+>	A record_component_association_list may only be a null record if no
+>components are needed for that list, and the list is not for  a
+>record_delta_aggregate.
+>
+>	or is that too simplistic?
+
+Just a bit. I wondered something similar (but decided to avoid more mail-box
+filling), but the problem is "needed" isn't defined for record_delta_aggregates.
+So the first part is meaningless for a record_delta_aggregate, and one wants to
+be able to evaluate rules left-to-right. Also, "a null record" is awkward, since
+we're talking about the keywords "null record" as opposed to an empty record.
+Also, "may only" is nasty from an ISO perspective; it would be better to use
+"shall" as this is a Legality Rule (I didn't mention that previously, but I was
+trying to make the wording more typical Standard-ease).
+
+OTOH, we could simplify my version in a different way:
+
+    A record_component_association_list shall be /null record/ only if the list
+    occurs in a record_aggregate or extension_aggregate, and there are no
+    components needed for that list.
+
+    AARM Ramification: /null record/ is not allowed at all in a
+    record_delta_aggregate.
+
+We don't have to mention record_delta_aggregates at all if we are only listing
+the positive rules.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, December  4, 2017  9:30 PM
+
+> Whew! Thoughts??? (Note: I haven't looked at the array rules yet; I
+> worry that they have similar issues. The record ones took all night
+> and I still need to do backups...so next week.)
+
+I've looked at the array rules now, and they are much better. All of the
+existing rules in 4.3.3 include some form of "for an array_aggregate", so we
+have a clean slate. (The record rules didn't do that because they are already
+shared between record and extension aggregates; sharing them with the third kind
+of aggregate seems best to handle that.)
+
+Two points:
+
+There is no need to mention "applicable index constraint" in the delta aggregate
+rules. We don't need an applicable index constraint for an array delta
+aggregate, as they cannot be either positional nor have an others choice. (The
+term does not appear elsewhere.)
+
+4.3.3(14) applies to the component expression of any aggregate, so it is fine;
+4.3.3(10) says that 4.3.3(14) applies to array_aggregates (only), but that is
+talking about the aggregate that is the component expression (the one that might
+have and others iff it is an array aggregate), and not the enclosing aggregate
+(which might be a delta aggregate). (If it was talking about the enclosing
+aggregate, record aggregates wouldn't provide an applicable index constraint,
+which is obvious nonsense.)
+
+Thus, there is no need to mention "applicable index constraint" in 4.3.4.
+(Not sure how Steve convinced us otherwise, but he was wrong.)
+
+---
+
+I think it would be good to explicitly define the bounds of the anonymous object
+of an array_delta_aggregate. Aggregates only have types (not subtypes), and in
+particular do not use the subtype of the aggregate to determine the bounds of a
+named array aggregate. I would expect that the same is true here (especially as
+there is no check that the bounds match any subtype; that happens later when the
+aggregate is converted to some subtype for use -- note again that there are no
+rules in 4.3.1 or 4.3.3 requiring a check on the actual bounds/discriminants of
+the subtype of the aggregate).
+
+Specifically, we should explicitly state that the "The bounds of the anonymous
+object of an array_delta_aggregate and the discriminants (if any) of the
+anonymous object of a record_delta_aggregate are those of the
+*base_*expression."
+
+Then (like all other aggregates), the subtype conversion that occurs when the
+aggregate is used (or qualified) will ensure that the subtype
+(bounds/discriminants) are appropriate.
+
+We have to be certain that all of the below raise Constraint_Error.
+
+     type Arr is array (Natural range <>) of Integer;
+     subtype Arr_0_3 is Arr(0..3);
+     subtype Arr_0_4 is Arr(0..4);
+     subtype Arr_1_5 is Arr(1..5);
+
+     procedure Do_It (P : in Arr_1_5);
+     function Fun return Arr;
+
+     Arr_Obj_1 : Arr_0_4 := ...;
+     Arr_Obj_2 : Arr_0_3 := ...;
+
+     Do_It ((Arr_Obj_1 with delta 2 => 3)); -- (1)
+     Do_It ((Arr_Obj_2 with delta 2 => 3)); -- (2)
+     Do_It ((Fun with delta 2 => 3)); -- (3)
+
+The aggregate at (1) has bounds of 0..4, which are different than the bounds of
+the subtype of 1..5. We don't want sliding here (array aggregates don't slide).
+The aggregate at (2) shows that sliding isn't enough anyway, here the number of
+components is wrong. The aggregate at (3) shows that the bounds aren't
+necessarily known at compile-time.
+
+------------------
+
+Given the lack of comment on the previous iterations (other than from Jeff), I'm
+just going to make all of these changes and plan on a letter ballot on this AI.
+So get any comments in sooner rather than later.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, December  4, 2017  9:40 PM
+
+Thanks for digging into this.  It sounds like you have come up with significant
+improvements, with a little help from Jeff.  I'll admit I haven't followed all
+of the discussion, but I will look forward to a new version.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Monday, December  4, 2017  10:27 PM
+
+> There is no need to mention "applicable index constraint" in the delta
+> aggregate rules. We don't need an applicable index constraint for an
+> array delta aggregate, as they cannot be either positional nor have an
+> others choice. (The term does not appear elsewhere.)
+
+What about in defining the applicable index constraint of the base expression,
+as in
+
+
+   X : String (1 .. 4) :=
+    ((others => 'X') with delta 1 => 'Y'); -- "YXXX"
+
+?
+
+I thought we had a rule that the applicable index constraint of the base
+expression is that (if any) of the delta aggregate. Ditto for expected type.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, December  4, 2017  10:41 PM
+
+That seems like a rule that should have existed, but the only rule in the most
+recent AI draft applied to the expressions of a component_list. (There is, of
+course, a rule for the expected type of a base_expression; it doesn't mention
+"applicable index constraint").
+
+In any case, such a rule belongs in 4.3.3 in the list of bullets (we don't want
+delta_aggregates to look "bolted on" in the Standard). Probably after 4.3.3(14)
+following the form of the other bullets:
+
+* For the *base_*expression of a delta_aggregate, if the nominal subtype of the
+  delta_aggregate is a constrained array subtype, the applicable index
+  constraint is the constraint of the subtype;
+
+I'll add that, too.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, December  5, 2017  6:42 PM
+
+Here are some comments on AI12-0127-1, noted as I put this into the draft RM.
+Treat these as my editorial review (noted here for the record, not requiring
+discussion):
+
+---
+
+I put the entire syntax on one line as it will fit (at least in the printed RM,
+the official ISO version) and it is much less disruption that way (else I'd have
+to delete most of it and replace it in the new format).
+
+---
+
+The next paragraph number is 4.3(3/2), not 4.3(3).
+
+---
+
+The wording of 4.3(4) should use record_aggregate and extension_aggregate with
+underscores and in the syntax font, like the rule it replaces and many others.
+
+---
+
+The last sentence of 4.3.1(9) says that the Selector_Name in a
+record_component_association has to denote a "needed" component. The next (newly
+added) paragraph gives a different rule for record_delta_aggregates (that
+doesn't use "needed"). That doesn't make sense as written, as the "needed" rule
+certainly seems to apply to any record_component_association, but we didn't
+define "needed" for delta aggregates. Since that was intentional (we don't want
+the "needed" rules to apply to a delta_aggregate), we need to modify the last
+sentence of 4.3.1(9) (along with adding the new paragraph) to make it clear that
+it does not apply to delta_aggregates.
+
+I did that by adding "of a record_aggregate or extension_aggregate" after
+record_component_association in the last sentence of 4.3.1(9).
+
+---
+
+The syntax change of 4.3.3 is in paragraph 4, not 3 as the AI says.
+
+---
+
+4.3.3(17/5) seems to be a bit of a run-on sentence, but I don't have a better
+idea. (This is the first paragraph that I didn't have an important comment on,
+and I didn't want to break the perfect streak... ;-)
+
+---
+
+In the 4.3.4 wording:
+
+* various "record aggregate", "array aggregate", and "delta aggregate"
+  references should have an underscore and be in the syntax font. (There's a
+  lot, so I won't list these individually.)
+
+* There are lots of real problems here, these are discussed in individual
+  messages sent previously.
+
+* in the first paragraph of the dynamic semantics, we have "aggregate's
+  anonymous object". John will require the possesive to be eliminated, so we
+  have to say "anonymous object of the aggregate".
+
+---
+
+The items in 7.5(2.1/5-2.10/3) are in the order that they appear in the RM. As
+such, the new item belongs after 7.5(2.6/2) -- which references 4.3.3 -- and not
+at the end. That does unfortunately change the paragraph numbers for the latter
+bullets, but it seems better to keep the order (and all of the aggregates
+together).
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, December  7, 2017  7:41 PM
+
+One last wording question about AI12-0127-1 (I'm done with this one now, so I
+ought to be moving on...)
+
+The Dynamic Semantics includes the sentence:
+
+In the case of an array component, the associated index expression is also
+evaluated and used in determining the target component just as in any array
+indexing operation.
+
+"just as in any array indexing operation" doesn't seem at all like
+Standards-speak. I've thought about this too much without any definitive
+replacement.
+
+The literal replacement:
+
+"in the same manner as an array indexing operation (see 4.1.1)"
+
+is better Standards-speak, but it still seems rather hand-wavy. The fact that
+there is an index check hidden here seems bad.
+
+I note that 4.1.1(7) is 4 short sentences, and the first already is included in
+the rule given above. The part about "determining the target component" really
+is just 4.1.1(5)'s "denotes the component of the array with the specified index
+value(s)". So an alternative is to just say what we mean:
+
+In the case of an array component, the associated index expression is also
+evaluated, then converted to the index type of the array type. A check is made
+that each index value belongs to the index range of the anonymous object of the
+aggregate; Constraint_Error is raised if this check fails. The component
+expression is evaluated and assigned to the component of the anonymous array
+object identified by the index value.
+
+AARM Discussion: This is the same semantics as a normal assignment to an
+individual indexed array component.
+
+Looking at the entire paragraph, all of it is vague and strangely written:
+
+Next, for each component for which an expression is provided, the expression is
+evaluated and assigned to that component of the anonymous object. In the case of
+an array component, the associated index expression is also evaluated and used
+in determining the target component just as in any array indexing operation. As
+with any aggregate, evaluation of a delta_aggregate then denotes the associated
+anonymous object.
+
+The last sentence is particularly bad: none of the existing aggregate rules ever
+discuss the anonymous object -- that isn't introduced until 7.6(17.1/3).
+
+Heat-vision aside: If we're going to talk about the anonymous object in 4.3.4,
+shouldn't we mention that it might have to be built in place? 7.6 says
+"aggregate", which clearly applies to delta aggregates, and it seems it has to
+in the limited case.
+
+I wonder if we would be better off separating the record and array cases and
+explain where the expression comes from, how the component is identified, and so
+on. Sigh -- another full rewrite.
+
+Thoughts? Suggestions? Tell me to forget about the dang AI and do something
+else?? :-)
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent