Version 1.7 of ai22s/ai22-0018-1.txt

• for a named_container_aggregate without an iterated_element_association, the number of key_expressions;

• for a named_container_aggregate where every iterated_element_association contains a loop_parameter_specification, the total number of elements specified by all of the container_element_associations;

• for a named_container_aggregate where each iterated_element_association, if any, contains a loop_parameter_specification, the total number of elements specified by all of the container_element_associations;

• an attribute_reference whose prefix denotes a non-generic entity that is not declared in a generic unit, and whose attribute_designator is Nonblocking;

From: Randy Brukardt [privately]
Sent: Monday, September 13, 2021  1:10 AM

When looking at the items to test, I noticed that the AARM says that we added 
wording to allow the Nonblocking attribute to be static. Of course, we deleted
that attribute. But, indeed, the wording remains in 4.9.

I guess if someone invents their own Nonblocking attribute, it will be static
some of the time. ;-)

Another minor thing to fix.

****************************************************************

[Summary of a private e-mail exchange between Randy Brukardt and Tucker Taft
in November 2021.]

[Randy] 4.3.5(50/5) says that an indexed aggregate is evaluated like a named
aggregate. But the wording in 4.3.5(46/5) does not take into account the
case where a choice is a discrete_range (since that isn't allowed for
Add_Named aggregates).

[Tucker Reply #1]
Not sure what makes you say that a discrete_range isn't permitted for 
Add_Named aggregates.   

[Randy Reply #1] 
4.3.5(26/5) says:
 
A container_element_association with a <> rather than an expression, or with 
a key_choice that is a discrete_range, is permitted only in an indexed 
aggregate.
 
An aggregate implemented with Add_Named is never an indexed aggregate. Hard 
to get any clearer than that. :-)

[Tucker Reply #2]
That looks like an unnecessary restriction to me.  As you mention below, we 
allow iterated_component_associations, one choice of which is a 
loop_parameter_specification, which can use a discrete_range.  And we allow 
a list of key_choices.  So I can't quite imagine why, if we allow
[1|2|3 => X], we don't also allow [1..3 => X].  I did a little spelunking 
into the history of this rule, and it turns out that before we invented (on 
your request!) the notion of indexed aggregates, we only allowed:

 key_expression | key_expression ... => expression

When we added indexed aggregates, it was clear we wanted to allow a 
discrete_range.  But for some reason I was reluctant to generalize them to 
all container aggregates.  But now I think I was just being overly
conservative.  They make perfect sense for any case where the key type is
discrete.  So I would change 4.3.5(26/5) to:

  A container_element_association with a <> rather than an expression[, or 
  with a key_choice that is a discrete_range,] is permitted only in an 
  indexed aggregate.

[Tucker Reply #1]
They are legal the way I read the rules.  In particular, the legality rule
in 4.3.5(27/5) seems to permit it so long as the discrete_range's type
matches that of the key type:
  For an iterated_element_association without a key_expression, if [...] the 
  expected type of the aggregate specifies an Add_Named procedure in its
  Aggregate aspect, then the type of the loop parameter of the 
  iterated_element_association shall be the same as the key type of the 
  aggregate. 
 
[Randy Reply #2]
That *could* have been the model, and IMHO, I think in hindsight that it 
*should* be the model, but 4.3.5(26/5) is crystal clear. 
 
Additionally, there is a minor hole here: a loop_parameter_specification 
can have a discrete_range, (legal if the key type of Add_Named is discrete
or there is a key expression). As such, there doesn't seem to be a ton of 
reason to disallow a discrete_range as a key_choice (assuming the type is 
OK). Maybe we should simply drop the part of 4.3.5(26/5) about the key_choice.

[Tucker Reply #2]
Great minds... 

****************************************************************

From: Randy Brukardt
Sent: Tuesday, November 16, 2021  12:00 AM

I noticed today a problem with the solution for the third question of
AI22-0018-1: the wording of 4.3.5(38/5) doesn't make sense if discrete_ranges
are allowed in choices. I think the best solution to that is to delete that
bullet entirely and add a parenthetical remark to the next one to make it
clear that it also applies if there are no iterated_element_associations. I've
updated the AI accordingly and reposted it (and updating everything with it,
hopefully).

Apologies for any inconvenience.

****************************************************************

From: Tucker Taft
Sent: Tuesday, November 16, 2021  7:51 AM

Or you could replace:
   ... the number of key_expressions;

with
   ... the total number of elements specified by all of the key_choices;

****************************************************************