!standard 4.3.5(24/5) 22-09-06 AI22-0018-1/05 !standard 4.3.5(26/5) !standard 4.3.5(38/5) !standard 4.3.5(39/5) !standard 4.9(8.1/5) !standard 13.1(0.1/3) !class binding interpretation 21-11-12 !status Corrigendum 1-2022 22-01-14 !status WG9 Approved 22-10-18 !status ARG Approved 13-0-0 21-11-18 !status work item 21-11-12 !status received 21-11-12 !priority Low !difficulty Easy !qualifier Omission !subject Easy fixes to Ada 2022 !summary A number of simple changes are suggested for Ada 2022. !issue (1) We decided in AI12-0396-1 that all aspects are either representation or operational aspects. However, not all aspects identify which class they are, for instance, Preelaborable_Initialization does not. That makes it hard to determine whether the rules are properly specified. Should this be fixed? (Yes.) (2) In 4.3.5(24/5), we mention every kind of aggregate other than a named aggregate with an iterator_specification without key_expressions. We intend no restriction on those, but given that we mention null aggregates (which also have no restriction), it seems like a mistake not to mention the last case. Should some wording be added? (Yes.) (3) In 4.3.5(26/5), we disallow discrete_ranges in key choices for container aggregates implemented by Add_Named. But there seems to be no reason for this restriction. A discrete_range is allowed in a loop_parameter_specification, so the needed implementation exists. Should it be dropped? (Yes.) (4) 4.9(8.1/5) mentions the "Nonblocking attribute", but that was removed during a rewrite of the nonblocking model. Should this rule be dropped? (Yes.) !recommendation (1) Add a rule such that an aspect that is not explicitly specified as a representation aspect is automatically assumed to be an operational aspect. (2) Add a sentence about the missing kind of aggregate. (3) Drop the restriction. Also fix-up the wording about calls to Empty to reflect the removal of the restriction. (4) Drop a rule about a nonexistent attribute. !wording (1) Modify 13.1(0.1/3): [Redundant: Two kinds of aspects of entities can be specified: representation aspects and operational aspects. Representation aspects affect how the types and other entities of the language are to be mapped onto the underlying machine. Operational aspects determine other properties of entities.] {When not specified otherwise, an aspect is defined to be an operational aspect.} [Note: As always, the square brackets here indicate that only the existing text is redundant, rather than representating a deletion.] (2) Modify 4.3.5(24/5): The expected type for a positional_container_aggregate shall have an Aggregate aspect that includes a specification for an Add_Unnamed procedure or an Assign_Indexed procedure. The expected type for a named_container_aggregate that contains one or more iterated_element_associations with a key_expression shall have an Aggregate aspect that includes a specification for the Add_Named procedure. The expected type for a named_container_aggregate that contains one or more key_choice_lists shall have an Aggregate aspect that includes a specification for the Add_Named or Assign_Indexed procedure. [Redundant: {For other kinds of named_container_aggregates, there are no additional restrictions on the Aggregate aspect of the expected type.} A null_container_aggregate can be of any type with an Aggregate aspect.] (3) Modify 4.3.5(26/5): 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. Delete 4.3.5(38/5): * for a named_container_aggregate without an iterated_element_association, the number of key_expressions; Modify 4.3.5(39/5): * for a named_container_aggregate where {each}[every] iterated_element_association{, if any,} contains a loop_parameter_specification, the total number of elements specified by all of the container_element_associations; (4) Delete 4.9(8.1/5): * an attribute_reference whose prefix denotes a non-generic entity that is not declared in a generic unit, and whose attribute_designator is Nonblocking; Also remove the AARM Note at 4.9(44.cc/5). !discussion (1) We could look at the definition of every aspect and decide if additional wording is needed. But that will continue to be required with every new edition of the RM. We chose instead to have all aspects be operational unless specified otherwise. (2) We wanted to make it clear that a null container aggregate can be of any type with an Aggregate aspect. But once we've done that, we've covered almost all of the cases, and it seems like the remaining cases are missing. We could have had an additional rule that a named_container_aggregate with an iterator_specification shall have a type with Add_Named or Add_Unnamed (as an indexed aggregate is not allowed for such an iterator), but the additional rule doesn't change what is or is not allowed. (3) For a discrete_range to be legal, the key type of the container type has to be discrete. But there is no problem describing the operation of such ranges, and indeed we have to do so anyway as the (dynamic semantics) wording is shared with indexed aggregates which do allow these. The original author of container aggregates thinks that the restriction came from an early version that existed before indexed aggregates were added. That makes it vestigal, and it should be eliminated. The Dynamic Semantics wording for the bulk of the implementation of container aggregates does not need a change for this relaxation, but the determination of the aggregate length wording in 4.3.5(38/5) does not make sense if some choices can be ranges. The wording in 4.3.5(39/5) works fine for this case, so we just delete 4.3.5(38/5) and add a parenthetical remark into 4.3.5(39/5) hopefully making it clear that it applies as well if there are no iterators at all. (4) When the attribute was deleted, this rule should have been removed as well, but obviously was not. !corrigendum 4.3.5(24/5) @drepl The expected type for a @fa shall have an Aggregate aspect that includes a specification for an Add_Unnamed procedure or an Assign_Indexed procedure. The expected type for a @fa that contains one or more @fas with a @i@fa shall have an Aggregate aspect that includes a specification for the Add_Named procedure. The expected type for a @fa that contains one or more @fas shall have an Aggregate aspect that includes a specification for the Add_Named or Assign_Indexed procedure. A @fa can be of any type with an Aggregate aspect. @dby The expected type for a @fa shall have an Aggregate aspect that includes a specification for an Add_Unnamed procedure or an Assign_Indexed procedure. The expected type for a @fa that contains one or more @fas with a @i@fa shall have an Aggregate aspect that includes a specification for the Add_Named procedure. The expected type for a @fa that contains one or more @fas shall have an Aggregate aspect that includes a specification for the Add_Named or Assign_Indexed procedure. For other kinds of @fas, there are no additional restrictions on the Aggregate aspect of the expected type. A @fa can be of any type with an Aggregate aspect. !corrigendum 4.3.5(26/5) @drepl A @fa with a <@> rather than an @fa, or with a @fa that is a @fa, is permitted only in an indexed aggregate. @dby A @fa with a <@> rather than an @fa is permitted only in an indexed aggregate. !corrigendum 4.3.5(38/5) @ddel @xinbull without an @fa, the number of @i@fas;> !corrigendum 4.3.5(39/5) @drepl @xinbull where every @fa contains a @fa, the total number of elements specified by all of the @fas;> @dby @xinbull where each @fa, if any, contains a @fa, the total number of elements specified by all of the @fas;> !corrigendum 4.9(8.1/5) @ddel @xbullet whose @fa denotes a non-generic entity that is not declared in a generic unit, and whose @fa is Nonblocking;> !corrigendum 13.1(0.1/3) @drepl Two kinds of aspects of entities can be specified: representation aspects and operational aspects. Representation aspects affect how the types and other entities of the language are to be mapped onto the underlying machine. Operational aspects determine other properties of entities. @dby Two kinds of aspects of entities can be specified: representation aspects and operational aspects. Representation aspects affect how the types and other entities of the language are to be mapped onto the underlying machine. Operational aspects determine other properties of entities. When not specified otherwise, an aspect is defined to be an operational aspect. !ACATS test (1) No ACATS test should be needed specifically for this rule, although additional tests might be needed for existing aspects if they were not previously identified as operational aspects. (2) No ACATS test is needed, this is redundant wording. (3) An ACATS C-Test should try a discrete range in an appropriate aggregate. (4) Can't test a nonexistent attribute in any useful way. !appendix 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; ****************************************************************