!standard 1.2(10/2) 22-02-04 AI12-0437-1/02 !standard 3.4.1(3/2) !standard 3.9(21) !standard 3.9.3(8/3) !standard 4.2.1(7/5) !standard 4.3.5(7/5) !standard 4.3.5(8/5) !standard 4.3.5(9/5) !standard 4.3.5(22/5) !standard 13.1.1(18.8/5) !standard A.18.2(88.1/3) !standard A.18.3(60.1/3) !standard A.18.3(158/2) !standard A.18.4(19.1/3) !standard A.18.4(81/2) !standard A.18.7(18.1/3) !standard A.18.7(102/2) !standard A.18.10(78/3) !standard B.3(60.8/2) !standard G.1.1(56) !standard G.1.1(57) !class presentation 21-11-11 !status Amendment 1-2012 22-01-07 !status WG9 Approved 22-06-22 !status ARG Approved 13-0-0 21-11-18 !status work item 21-11-11 !status received 21-04-16 !priority Low !difficulty Easy !qualifier Omission !subject Presentation issues in Ada 202x submission !summary Various presentation issues which have no effect on semantics are fixed. [Editor's note: This AI was approved as AI22-0001-1; it was then decided to apply these as editorial fixes to the Ada 2022 RM. Thus, this AI was renumbered; it is otherwise unchanged. See the start of the !discussion below. During ARG meeting #62N, a number of additional issues were added to this AI as editorial fixes to the Ada 2022 RM. Those issues are numbers 8 through 12. They were approved by a vote of 16-0-0 on 22-02-04.] !question (1) There appears to be a missing word in 4.2.1(7/5): When a numeric literal is interpreted as a value of a non-numeric type T or a string_literal is interpreted {as} a value of a type T that is not a string type (see 4.2), it is equivalent to a call to the subprogram denoted by the corresponding aspect of T: ... Agreed? (Yes.) (2) 4.3.5(6/5) says that the name should denote "exactly one" function. However, 4.3.5(7-9/5) does not include the "exactly one" wording. Is this significant or an omission? (An omission.) (3) 4.3.5(22/5) just says that the type of a container aggregate has to be a container type. All of the other kinds of aggregates (for instance, in 4.3.3(7/2) for array aggregates) require this to be some sort of "single" type. Is "single" missing here? (Yes.) (4) 13.1.1(18.8/5) is a redundant list of all of the nonoverridable aspects. User-defined literal aspects are nonoverridable but not in this list. Should they be added? (No, the list should be eliminated.) (5) Between A.15 and A.17, some text has a hyphen in "implementation-defined" and other text does not. Should this be consistent? (No, but some uses are wrong.) (6) 3.9(21) has a comma before "identifies T" while 3.9(20) and 3.9(23) do not. Should these be consistent? (Yes.) (7) In 3.9.3(8/3), the first sentence is confusing. Should we remove the first "or" and insert "of" after the third "or"? (Yes.) (8) In 3.4.1(3/2), use "one of" rather than "either" since this is a choice of three options, not two. Change? (Yes.) (9) [WG 9 comment #178] In A.18.2(88.1/3) "It also may write..." would be better as "It may also write...". There are 20 instances of "may also" in the AARM but only a few "also may". And most of them are this same sentence but with vector replaced by set, map, and so on. These occur in A.18.3(60.1/3), A.18.4(19.1/3), A.18.7(18.1/3), and A.18.10(78/3). Change these? (Yes.) (10) [WG 9 comment #179] In A.18.2(253/2), we say "vector object" all in lower case. A.18.3(158/2) says "doubly-linked List object", with List capitalized. Similarly, A.18.4(81/2) says "a Map object" and A.18.7(102/2) says "a Set object", while A.18.10(229/3) says "a multiway tree object". Make these consistent? (Yes.) (11) G.1.1(56,57) refer to IEC 559:1989, however the current standard is ISO/IEC 60559:2020. Moreover, neither of these standards is referenced in the Normative References clause (where all referenced Standards should appear). Correctly handle these? (Yes.) (12) B.3(60.8/2) says: The result of Is_Nul_Terminated is True if Item contains char16_nul, and is False otherwise. But this is under a function that takes a char32_array, so this paragraph should mention char32_nul instead of char16_nul, right? (Yes.) !recommendation (See Summary.) !wording (1) Modify 4.2.1(7/5): When a numeric literal is interpreted as a value of a non-numeric type T or a string_literal is interpreted {as} a value of a type T that is not a string type (see 4.2), it is equivalent to a call to the subprogram denoted by the corresponding aspect of T: ... (2) Modify 4.3.5(7/5): The procedure_name specified for Add_Unnamed for an Aggregate aspect shall denote {exactly one}[a] procedure that has two parameters, the first an in out parameter of the container type, and the second an in parameter of some nonlimited type, called the element type of the container type. Modify 4.3.5(8/5): The function_name specified for New_Indexed for an Aggregate aspect shall denote {exactly one}[a] function with a result type of the container type, and two parameters of the same discrete type, with that type being the key type of the container type. Modify 4.3.5(9/5): The procedure_name specified for Add_Named or Assign_Indexed for an Aggregate aspect shall denote {exactly one}[a] procedure that has three parameters, the first an in out parameter of the container type, the second an in parameter of a nonlimited type (the key type of the container type), and the third, an in parameter of a nonlimited type that is called the element type of the container type. (3) Modify 4.3.5(22/5): The expected type for a container_aggregate shall be a {single} type for which the Aggregate aspect has been specified. The expected type for each expression of a container_aggregate is the element type of the expected type. (4) Delete 13.1.1(18.8/5) Add after 13.1.1(18.3/5): AARM Discussion: A list of all nonoverridable aspects can be found in the index, under "nonoverridable aspect". [Editor's note: This index entry is new, also added for this AI.] (5) Remove the hyphen from "implementation-defined" in A.16(46/2, 57/2, 61/3, 69/3, 76/2, 93/2, 95/2, 104/3, 110/3, 112/3, 114/3, 120/2, 122/2). [Editor's note: This will be a "silent" typo-fix, without any change markings. As such, we don't need any !corrigendum sections for this change.] (6) Modify 3.9(21): The tag of an object created by an allocator for an access type with a specific designated tagged type T[,] identifies T. (7) Modify 3.9.3(8/3): The type of an aggregate, [or] of an object created by an object_declaration or an allocator, or {of} a generic formal object of mode in, shall not be abstract. The type of ... (8) Modify 3.4.1(3/2): Every type is {one of}[either] a *specific* type, a *class-wide* type, or a *universal* type. A specific type is one defined by a type_declaration, a formal_type_declaration, or a full type definition embedded in another construct. Class-wide and universal types are implicitly defined, to act as representatives for an entire class of types, as follows: (9) Modify A.18.2(88.1/3): Vector'Write for a Vector object V writes Length(V) elements of the vector to the stream. It {may }also[ may] write additional information about the vector. Modify A.18.3(60.1/3): List'Write for a List object L writes Length(L) elements of the list to the stream. It {may }also[ may] write additional information about the list. Modify A.18.4(19.1/3): Set'Write for a Set object S writes Length(S) elements of the set to the stream. It {may }also[ may] write additional information about the set. Modify A.18.7(18.1/3): Set'Write for a Set object S writes Length(S) elements of the set to the stream. It {may }also[ may] write additional information about the set. Modify A.18.10(78/3): Tree'Write for a Tree object @i writes Node_Count(@i) - 1 elements of the tree to the stream. It {may }also[ may] write additional information about the tree. (10) Modify A.18.3(158/2): No storage associated with a doubly-linked {list}[List] object shall be lost upon assignment or scope exit. Modify A.18.4(81/2): No storage associated with a {map}[Map] object shall be lost upon assignment or scope exit. Modify A.18.7(102/2): No storage associated with a {set}[Set] object shall be lost upon assignment or scope exit. (11) Add after 1.2(10/2): ISO/IEC 60559:2020, *Information technology -- Microprocessor Systems -- Floating-Point arithmetic* Modify G.1.1(56): Because the usual mathematical meaning of multiplication of a complex operand and a real operand is that of the scaling of both components of the former by the latter, an implementation should not perform this operation by first promoting the real operand to complex type and then performing a full complex multiplication. In systems that, in the future, support an Ada binding to {ISO/IEC 60559:2020}[IEC 559:1989], the latter technique will not generate the required result when one of the components of the complex operand is infinite. (Explicit multiplication of the infinite component by the zero component obtained during promotion yields a NaN that propagates into the final result.) Analogous advice applies in the case of multiplication of a complex operand and a pure-imaginary operand, and in the case of division of a complex operand by a real or pure-imaginary operand. Modify G.1.1(57): Likewise, because the usual mathematical meaning of addition of a complex operand and a real operand is that the imaginary operand remains unchanged, an implementation should not perform this operation by first promoting the real operand to complex type and then performing a full complex addition. In implementations in which the Signed_Zeros attribute of the component type is True (and which therefore conform to {ISO/IEC 60559:2020}[IEC 559:1989] in regard to the handling of the sign of zero in predefined arithmetic operations), the latter technique will not generate the required result when the imaginary component of the complex operand is a negatively signed zero. (Explicit addition of the negative zero to the zero obtained during promotion yields a positive zero.) Analogous advice applies in the case of addition of a complex operand and a pure-imaginary operand, and in the case of subtraction of a complex operand and a real or pure-imaginary operand. (12) Modify B.3(60.8/2): The result of Is_Nul_Terminated is True if Item contains {char32_nul}[char16_nul], and is False otherwise. !discussion Overall: All of these fixes are just presentation changes that ought to have no semantic effect. They should be treated as "typos" (using an expansive definition of that) and fixed in the final version of the Ada 202x documents. (1) This is just an obvious typo. (2) We don't want there to be multiple element types for a container aggregate, as we don't want to complicate aggregate resolution (no other aggregate allows multiple element types). As such, only a single subprogram can be allowed for each of these names. Note that isn't a given, as some other aspects, like Variable_Indexing, can represent a set of overloaded functions. As such, we want to be crystal-clear here and include the "exactly one" wording -- and it is important to have each of these paragraphs worded similarly. (3) 4.3(3/5) does require "single" types, so that is covered, but it is still inconsistent with all other aggregates to not repeat that. So we make this wording consistent. (4) Maintaining this list has been a nightmare: no one remembers to add new aspects to it until someone stumble upon it and notices that something is missing. We don't need this text, each such aspect already explicitly says that it is nonoverridable where it is defined. Therefore, we suggest deleting it; there is a boilerplate for saying that an aspect is nonoverridable (it always includes a reference to 13.1.1) and hopefully when that gets copied the index entry will come along with it. At least that is more likely than a list a long ways away getting updated. (5) "implementation defined" is hyphened when used as a modifier, and not when used stand alone. (That goes for many other phrases as well, such as "stand alone".) Thus, we have "Foobar is implementation defined" and "Glarch has an implementation-defined version". We fix uses that hyphenate incorrectly. Note that we leave the hyphen in declarations (it appears in italics), as a space in a declaration would make it syntactically incorrect. (6) It appears that 3.9(20) does not have a comma before "identifies T" in order to avoid causing grouping confusion with the other commas in the bullet. But why 3.9(21) and 3.9(23) differ on the comma escapes your editor. He'd rather that all of these were consistent, and since a comma doesn't work in the first bullet, we remove it from the only one that has a comma before "identifies T". (7) This sentence has the structure "A, or B, or C" (with B containing an "or" itself). This would usually be written "A, B, or C". The suggested "of" also helps readability. (8) "Either" should only be used with two item (as in "either or"); we have three here. We could have dropped "either", but it is better to replace it with "one of" to show that the choice is mutually exclusive. (9) As "may also" is more common in the RM, we change the text to use that. (10) As the text reads better without the capital letters, we change the wording to lower case all of the text in these cases. (11) As Standards should not reference superseded Standards unless absolutely necessary, we update the uses to point to ISO/IEC 60559:2020. We also add this Standard to the list in 1.2 Normative References. An alternative would be to eliminate the references from G.1.1(56-57). The first use is especially suspicious, given that it references something that might happen "in the future" (and which was rejected for Standardization in 2004 - see AI95-0315-1). However, since most hardware is IEEE today, it seems reasonable to retain the advice. (12) A char32_array contains char32_t characters, and thus we need to use the char32_t version of nul (char32_nul). !corrigendum 1.2(10/2) @dinsa ISO/IEC TR 19769:2004, @i. @dinst ISO/IEC 60559:2020, @i. !corrigendum 3.4.1(3/2) @drepl Every type is either a @i type, a @i type, or a @i type. A specific type is one defined by a @fa, a @fa, or a full type definition embedded in another construct. Class-wide and universal types are implicitly defined, to act as representatives for an entire class of types, as follows: @dby Every type is one of a @i type, a @i type, or a @i type. A specific type is one defined by a @fa, a @fa, or a full type definition embedded in another construct. Class-wide and universal types are implicitly defined, to act as representatives for an entire class of types, as follows: !corrigendum 3.9(21) @drepl @xbullet, identifies @i.> @dby @xbullet identifies @i.> !corrigendum 3.9.3(8/3) @drepl The type of an @fa, or of an object created by an @fa or an @fa, or a generic formal object of mode @b, shall not be abstract. The type of the target of an assignment operation (see 5.2) shall not be abstract. The type of a component shall not be abstract. If the result type of a function is abstract, then the function shall be abstract. If a function has an access result type designating an abstract type, then the function shall be abstract. The type denoted by a @fa (see 6.5) shall not be abstract. A generic function shall not have an abstract result type or an access result type designating an abstract type. @dby The type of an @fa, of an object created by an @fa or an @fa, or of a generic formal object of mode @b, shall not be abstract. The type of the target of an assignment operation (see 5.2) shall not be abstract. The type of a component shall not be abstract. If the result type of a function is abstract, then the function shall be abstract. If a function has an access result type designating an abstract type, then the function shall be abstract. The type denoted by a @fa (see 6.5) shall not be abstract. A generic function shall not have an abstract result type or an access result type designating an abstract type. !corrigendum 4.2.1(0) @dinsc See the conflict file for the changes. !corrigendum 4.3.5(0) @dinsc See the conflict file for the changes. !corrigendum 13.1.1(18.6/4) !comment This was the original paragraph number, AI12-0211-1 changed it. !comment We have to use the original number here so that a conflict is !comment properly detected. @ddel The Default_Iterator, Iterator_Element, Implicit_Dereference, Constant_Indexing, Variable_Indexing, Aggregate, Max_Entry_Queue_Length, and No_Controlled_Parts aspects are nonoverridable. !corrigendum A.18.2(88.1/3) @drepl Vector'Write for a Vector object @i writes Length(@i) elements of the vector to the stream. It also may write additional information about the vector. @dby Vector'Write for a Vector object @i writes Length(@i) elements of the vector to the stream. It may also write additional information about the vector. !corrigendum A.18.3(60.1/3) @drepl List'Write for a List object @i writes Length(@i) elements of the list to the stream. It also may write additional information about the list. @dby List'Write for a List object @i writes Length(@i) elements of the list to the stream. It may also write additional information about the list. !corrigendum A.18.3(158/2) @drepl No storage associated with a doubly-linked List object shall be lost upon assignment or scope exit. @dby No storage associated with a doubly-linked list object shall be lost upon assignment or scope exit. !corrigendum A.18.4(19.1/3) @drepl Map'Write for a Map object @i writes Length(@i) elements of the map to the stream. It also may write additional information about the map. @dby Map'Write for a Map object @i writes Length(@i) elements of the map to the stream. It may also write additional information about the map. !corrigendum A.18.4(81/2) @drepl No storage associated with a Map object shall be lost upon assignment or scope exit. @dby No storage associated with a map object shall be lost upon assignment or scope exit. !corrigendum A.18.7(18.1/3) @drepl Set'Write for a Set object @i writes Length(@i) elements of the set to the stream. It also may write additional information about the set. @dby Set'Write for a Set object @i writes Length(@i) elements of the set to the stream. It may also write additional information about the set. !corrigendum A.18.7(102/2) @drepl No storage associated with a Set object shall be lost upon assignment or scope exit. @dby No storage associated with a set object shall be lost upon assignment or scope exit. !corrigendum A.18.10(78/3) @drepl Tree'Write for a Tree object @i writes Node_Count(@i) - 1 elements of the tree to the stream. It also may write additional information about the tree. @dby Tree'Write for a Tree object @i writes Node_Count(@i) - 1 elements of the tree to the stream. It may also write additional information about the tree. !corrigendum B.3(60.8/2) @drepl @xindent @dby @xindent !corrigendum G.1.1(56) @drepl Because the usual mathematical meaning of multiplication of a complex operand and a real operand is that of the scaling of both components of the former by the latter, an implementation should not perform this operation by first promoting the real operand to complex type and then performing a full complex multiplication. In systems that, in the future, support an Ada binding to IEC 559:1989, the latter technique will not generate the required result when one of the components of the complex operand is infinite. (Explicit multiplication of the infinite component by the zero component obtained during promotion yields a NaN that propagates into the final result.) Analogous advice applies in the case of multiplication of a complex operand and a pure-imaginary operand, and in the case of division of a complex operand by a real or pure-imaginary operand. @dby Because the usual mathematical meaning of multiplication of a complex operand and a real operand is that of the scaling of both components of the former by the latter, an implementation should not perform this operation by first promoting the real operand to complex type and then performing a full complex multiplication. In systems that, in the future, support an Ada binding to ISO/IEC 60559:2020, the latter technique will not generate the required result when one of the components of the complex operand is infinite. (Explicit multiplication of the infinite component by the zero component obtained during promotion yields a NaN that propagates into the final result.) Analogous advice applies in the case of multiplication of a complex operand and a pure-imaginary operand, and in the case of division of a complex operand by a real or pure-imaginary operand. !corrigendum G.1.1(57) @drepl Likewise, because the usual mathematical meaning of addition of a complex operand and a real operand is that the imaginary operand remains unchanged, an implementation should not perform this operation by first promoting the real operand to complex type and then performing a full complex addition. In implementations in which the Signed_Zeros attribute of the component type is True (and which therefore conform to IEC 559:1989 in regard to the handling of the sign of zero in predefined arithmetic operations), the latter technique will not generate the required result when the imaginary component of the complex operand is a negatively signed zero. (Explicit addition of the negative zero to the zero obtained during promotion yields a positive zero.) Analogous advice applies in the case of addition of a complex operand and a pure-imaginary operand, and in the case of subtraction of a complex operand and a real or pure-imaginary operand. @dby Likewise, because the usual mathematical meaning of addition of a complex operand and a real operand is that the imaginary operand remains unchanged, an implementation should not perform this operation by first promoting the real operand to complex type and then performing a full complex addition. In implementations in which the Signed_Zeros attribute of the component type is True (and which therefore conform to ISO/IEC 60559:2020 in regard to the handling of the sign of zero in predefined arithmetic operations), the latter technique will not generate the required result when the imaginary component of the complex operand is a negatively signed zero. (Explicit addition of the negative zero to the zero obtained during promotion yields a positive zero.) Analogous advice applies in the case of addition of a complex operand and a pure-imaginary operand, and in the case of subtraction of a complex operand and a real or pure-imaginary operand. !ACATS test No ACATS tests needed for presentation changes. !appendix From: Jeff Cousins WG 9 Review issue #26 - April 16, 2021 [Comment on 3.4.1(3/2).] "one of" rather than "either" since a choice of 3 options, not 2. **************************************************************** From: Randy Brukardt WG 9 Review issue #26 - May 25, 2021 I think I prefer "either" here, even if it is strictly incorrect. In any case, this is old text that is not wrong (in an Ada sense), so it is out of bounds for this review. Thus it is deferred, see issue #15 for more. **************************************************************** From: Jeff Cousins WG 9 Review issue #34 - April 16, 2021 3.9(20) Maybe add a comma after "type T". **************************************************************** From: Jeff Cousins WG 9 Review issue #35 - April 16, 2021 3.9.3(8/3) Maybe remove the first "or" and insert "of" after the third "or". **************************************************************** From: Pat Rogers WG 9 Review issue #77 - April 18, 2021 I am never sure about the rules for hyphens in implementation=defined. But this one [A.5(12/3)] does not have a hyphen. However, all instances of implementation-defined in A.16 have a hyphen. But A.17 (1/2) does not have a hyphen. Nor does B.1(11/3). **************************************************************** From: Pat Rogers WG 9 Review issue #92 - April 18, 2021 [Comment on G.2.3 (21).] There are two mathematical expressions in this. One flows over the end of line. Maybe close them up and use × to give simply (l×r)/s and l/(r×s) **************************************************************** From: Randy Brukardt WG 9 Review issue #92 - May 28, 2021 This has been true in every edition of Ada in the 2000s, so it hardly a critical issue. Moreover, this is original Ada 95 text which is unchanged and not wrong, so it is out of bounds for this review -- we're not "improving" text at this time. See #15 for more. [Editor's note: Since these expressions are small, the easiest solution to keeping these expressions together is to put no-break spaces between the parts of the expressions. This will look the same as before (thus requiring no change to the language definition), but will keep the expressions from being split across lines. As this is a typographical change, it does not require inclusion in an AI.] **************************************************************** From: Randy Brukardt WG 9 Review issue #178 - June 3, 2021 Split from Issue #120, by John Barnes, May 5th. A.18.2 88.1/3 "It also may write..." perhaps better as "It may also write..." There are 20 instances of "may also" in the AARM but only a few "also may". And most of them are this same sentence but with vector replaced by set, map, and so on. A.18.3(60.1/3), A.18.4(19.1/3), A.18.7(18.1/3), A.18.10(78/3). For the record the AARM ones are in 4.5.7 (7.j/3), 5.5.2 (8.a/5), and 12.5.1 (28.c/2). **************************************************************** From: Randy Brukardt WG 9 Review issue #178 - June 3, 2021 The wording here is unchanged Ada 2012 wording that is not wrong. “Improvements” in such wording are considered out of bounds for this review. See also my reply to #15. **************************************************************** From: Randy Brukardt WG 9 Review issue #179 - June 3, 2021 Split from #121, #122, #123, by John Barnes, May 5th. A.18.3(158/2) perhaps say "doubly-linked list object" all in lower case to match vectors etc A,18.4(81/2) maybe "a map object" all in lower case to match others A.18.7(102/2) maybe "a set object" in lower case to match others **************************************************************** From: Randy Brukardt WG 9 Review issue #179 - June 3, 2021 This is original unmodified Ada 2005 wording. Moreover, of that Ada 2005 wording, only vectors is in lower case. It would make just as much sense to modify the wording to put Vector and Tree in upper case; that would be more consistent with the original wording. In any case, this is unmodified wording that is not wrong in any case; "improvements" of existing wording is out of bounds for this review. Also see my response to #15 for more. **************************************************************** From: Jean-Pierre Rosen Sent: Sunday, July 11, 2021 4:11 AM (noticed as a side effect of my reviews for WG23/vulnerabilities) G.1.1(56,57) refer to IEC 559:1989, however the current standard is ISO/IEC 60559:2020. Moreover, neither of these standards is referenced in the index. [Editor's note: I think he means the "Normative References" clause, which is supposed to list all of the referenced standards.] **************************************************************** From: Tucker Taft Sent: Wedenesday, July 14, 2021 7:17 AM There is a missing word in 4.2.1(7/5): When a numeric literal is interpreted as a value of a non-numeric type T or a string_literal is interpreted {as} a value of a type T that is not a string type (see 4.2), it is equivalent to a call to the subprogram denoted by the corresponding aspect of T: ... **************************************************************** From: Randy Brukardt Sent: Wedenesday, July 14, 2021 10:46 PM It's too late to fix this in the submission copy (and it's been wrong since at least January 2020), but as we're usually able to fix typos at any point, it's likely that we'll have some point when it can be fixed. And I fixed it in my local source files, so the next time the documents are generated (at least for a printed version) it will be fixed. **************************************************************** From: Randy Brukardt [privately] Sent: Tuesday, November 9, 2021 5:59 PM [Note: part of a much larger private e-mail seeking clarifications on 4.3.5 and related rules.] 4.3.5(7-9/5) requires a profile for the function or procedure, but doesn't say anything about there needing to be exactly one such subprogram. Even if the intent is to use usual "ambiguity" rules to deal with this, I note that 4.3.5(6/5) does use "exactly one", the difference is jarring. I'd guess that this wording was patterned after 4.1.6, but there we did want to allow a set of overloaded routines. Here (I think) we are only allowing there to be one element type, as otherwise the resolution of aggregates would get messy (and they'd be much less like array aggregates). **************************************************************** From: Tucker Taft [privately] Sent: Tuesday, November 9, 2021 5:59 PM I agree these should say "exactly one." **************************************************************** From: Randy Brukardt [privately] Sent: Tuesday, November 9, 2021 5:59 PM [Note: part of a much larger private e-mail seeking clarifications on 4.3.5 and related rules.] (10) 4.3.3(7/2) requires an array aggregate to be a single array type. 4.3.5(22/5) only requires a container aggregate to be a container type. Is "single" missing here? (Yes and no: 4.3(3/5) requires a single container type, but all of the other aggregate kinds, including the new delta aggregates, repeat "single". So there's no hole, but still a mistake.) **************************************************************** From: Randy Brukardt [privately] Sent: Tuesday, November 9, 2021 7:00 PM [Note: This was part of a much larger thread. Only the parts significant to this question are included here.] 13.1.1(18.8/5) gives a list of nonoverridable aspects, which is always wrong. For instance, the xxx_Literal aspects are missing now. Could we change this to an AARM note that points to the index? (I'd have to add the aspects to the index in this way, but that seems like a good idea anyway.) I'm tired of this being forever wrong. (It's never been right in any "final" edition of the RM.) **************************************************************** From: Tucker Taft [privately] Sent: Thursday, November 11, 2021 10:08 AM That is fine with me, so long as we are careful to use the word "nonoverridable" on the definition of each such aspect. [Editor's note: They all do, I checked.] **************************************************************** From: Tucker Taft Sent: Tuesday, November 16, 2021 6:56 AM Yannick Moy noticed the following typo in http://www.ada-auth.org/standards/2xrm/html/RM-B-3.html : 60.7/2 function Is_Nul_Terminated (Item : in char32_array) return Boolean; 60.8/2 The result of Is_Nul_Terminated is True if Item contains char16_nul, and is False otherwise. The line above should mention char32_nul instead of char16_nul. ****************************************************************