CVS difference for ai22s/ai22-0023-1.txt
--- ai22s/ai22-0023-1.txt 2022/02/04 03:54:24 1.2
+++ ai22s/ai22-0023-1.txt 2022/02/05 05:28:46 1.3
@@ -1,23 +1,8 @@
-!standard 1.1.2(35) 22-02-03 AI22-0023-1/02
-!standard 1.2(10/2)
-!standard 3.4.1(3/2)
+!standard 1.1.2(35) 22-02-04 AI22-0023-1/02
!standard 3.8(18/2)
-!standard 7.3.2(1/5)
!standard 7.3.2(5/5)
-!standard 8.3(26/2)
!standard 9.2(7)
!standard 10.2.1(18/3)
-!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 22-01-19
!status Corrigendum 1-2022 22-02-03
!status ARG Approved 16-0-0 22-02-03
@@ -40,67 +25,22 @@
of what certain performance characteristics are for an implementation.
Change? (Yes.)
-(3) [WG 9 comment #26] In 3.4.1(3/2), use "one of" rather than "either"
-since this is a choice of three options, not two. Change? (Yes.)
-
-(4) [WG 9 comment #32] In 3.8(18/2), the first reference to 9.5.2 seems
+(3) [WG 9 comment #32] In 3.8(18/2), the first reference to 9.5.2 seems
incorrect, maybe it should be 3.6? (No.)
-
-(5) [WG 9 comment #148] It would help readers if the intro of 7.3.2 were to
-explain that the aim of the Type_Invariant('Class) feature is to ensure that
-any object of this type/class satisfies the invariant when inspected or used
-by a client of the defining package, but the invariant does not have to be
-satisfied at each point within the operations of the defining package itself
-(where the full type declaration is visible). Therefore, the invariant is
-checked at the boundary between the defining package and its clients. Should
-this be done? (Yes.)
-
-(6) [WG 9 comment #150] 8.3(26/2) starts by stating several rules for various
-things, and then says "These rules also apply to dispatching operators
-declared in the visible part of an instance of a generic unit". The part
-"these rules" is confusing, because some of the rules stated earlier in the
-paragraph apply to type extensions or to context clauses, neither of which
-seems relevant to declarations of dispatching operations. Should this be
-clarified? (???.)
-(7) [WG 9 comment #154] The note 9.2(7) leaves me hanging in suspense: what
+(4) [WG 9 comment #154] The note 9.2(7) leaves me hanging in suspense: what
happens if a task entry is called before the task is activated? Probably the
caller task is blocked until the callee task either has been activated and
accepts the entry call, or becomes terminated for some reason. Should the note
should be extended to say what happens? (No.)
-(8) [WG 9 comment #177] In 7.3.3(4/5) the phrase "a name that denotes the
+(5) [WG 9 comment #177] In 7.3.3(4/5) the phrase "a name that denotes the
declaration" is referring to the current instance of the type. But the
analogous definition of Type_Invariant in 7.3.2(5/5) uses a different
phrase: "the identifier of the first subtype of the associated type". It seems
that the wording should be the same in these two places, should something be
changed? (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.)
@@ -132,18 +72,8 @@
Documentation requirements for metrics of the time/space properties of the
execution of certain language constructs.
-(3) Modify 3.4.1(3/2):
+(3) Modify 3.8(18/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:
-
-[Move this to AI12-0437-1.]
-
-(4) Modify 3.8(18/2):
-
Within the definition of a composite type, if a component_definition{ of
a component_declaration} or discrete_subtype_definition{ of an
entry_declaration for an entry family} (see 9.5.2) includes a name that
@@ -167,47 +97,10 @@
[Editor's note: This mainly repeats the more detailed wording found near the
second reference to 9.5.2 for the first reference. It clarifies why we're
referring to 9.5.2 instead of somewhere else.]
-
-(5) Add before 7.3.2(1/5):
-
- A type invariant is an assertion about the state of objects
- of a type exported by a package. The type invariant is enforced on
- objects used by clients of the package; it is generally not enforced on
- objects inside of the package. Similarly, a class-wide type invariant is an
- assertion of about the state of all objects of a class of types outside of
- the package defining the specific type of the class.
-
-(6) Modify 8.3(26/2):
-
- A non-overridable declaration is illegal if there is a homograph occurring
- immediately within the same declarative region that is visible at the place of
- the declaration, and is not hidden from all visibility by the non-overridable
- declaration. In addition, a type extension is illegal if somewhere within its
- immediate scope it has two visible components with the same name. Similarly,
- the context_clause for a compilation unit is illegal if it mentions (in a
- with_clause) some library unit, and there is a homograph of the library
- unit that is visible at the place of the compilation unit, and the homograph
- and the mentioned library unit are both declared immediately within the same
- declarative region. These rules {that apply to subprograms }also apply to
- dispatching operations declared in the visible part of an instance of a
- generic unit. However, they do not apply to other overloadable declarations
- in an instance; such declarations may have type conformant profiles in the
- instance, so long as the corresponding declarations in the generic were not
- type conformant.
-
-Add after AARM 8.3(26.k):
-
- AARM Ramification: The type extension component rule obviously does not
- apply to dispatching operations in an instance. However, the context clause
- rule could apply, as a compilation unit can be a subprogram.
-
-[Editor's note: I'm unsure that the wording added to the normative wording
-actually helps anything. Perhaps we should just add an AARM note like the one
-given??]
-(7) No wording change recommended.
+(4) No wording change recommended.
-(8) Modify 7.3.2(5/5):
+(5) Modify 7.3.2(5/5):
Within an invariant expression, {a name that denotes the associated type
declaration is interpreted as denoting}[the identifier of
@@ -221,92 +114,6 @@
the only operations that can be applied to this
current instance are those defined for such a formal derived type.
-(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<T> writes Node_Count(@i<T>) - 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
We deferred all presentation comments on the Ada 2022 draft if they were on
@@ -317,45 +124,25 @@
A few of these issues were raised after the WG 9 review.
-[Editor's note: I've included all of the changes suggested by the WG 9 review
-other than typography comments so that the ARG can consider them. Deciding
-to change nothing is an acceptable result for most of these issues, other than
-(11) and (12).]
-
(1) A bulleted list makes this much easier to read.
(2) Metrics is a special case of documentation requirements and this paragraph
should say that.
-
-(3) Unclear to the author that this is an improvement.
-(4) The only way that a discrete_subtype_definition can appear in a composite
+(3) The only way that a discrete_subtype_definition can appear in a composite
type is as the entry family of and entry declaration. (They also appear in
chunk_specification, constrained_array_definition, and
loop_parameter_specification, but none of those can appear in a
component_definition or protected_element_declaration.) This is mentioned
in the next sentence of the paragraph, but that's a bit late.
-(5) Most subclauses have some sort of introduction, it's unusual that this one
-does not.
-
-(6) The last two sentences of 8.3(26/2) are original Ada 95 wording. At that
-time, the rule about type extension components did not exist, and the context
-clause rule was only about subunits. In that case, it is fairly clear how
-both of these rules could apply in the generic instance case (since a subunit
-can be a completion of a dispatching operation).
-
-Later bug fixes broadened the subunit rule to any compilation unit, and the type
-extension rule was added. After those changes, the connection to the later
-sentences was lost.
-
-(7) This subclause occurs before the description of entry calls, so we don't
+(4) This subclause occurs before the description of entry calls, so we don't
want to say very much about the mechanism of the calls. Indeed, it's unclear
that we should be talking about entry calls at all here. But given that this
note is unchanged from original Ada 95, there seems to be little reason to
make a change at this time (either deleting or expanding the note).
-(8) 8.6 (17-18), which formally define "current instance" of a type, talk
+(5) 8.6 (17-18), which formally define "current instance" of a type, talk
of a "usage name" denoting "the same declaration of the type". So, the use of
"identifier" in 7.3.2(5/4) is too narrow (it does not include renames, for
instance). We change the wording to be more like that of 7.3.3(4/5).
@@ -363,24 +150,6 @@
Note that this text is considered Redundant and should not affect the
semantics of the language.
-(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.1.2(35)
@drepl
@@ -390,31 +159,6 @@
Documentation requirements for metrics of the time/space properties of the
execution of certain language constructs.
-!corrigendum 1.2(10/2)
-
-@dinsa
-ISO/IEC TR 19769:2004, @i<Information technology @emdash Programming languages,
-their environments and system software interfaces @emdash Extensions for the
-programming language C to support new character data types>.
-@dinst
-ISO/IEC 60559:2020, @i<Information technology @emdash Microprocessor Systems
-@emdash Floating-Point arithmetic>
-
-!corrigendum 3.4.1(3/2)
-
-@drepl
-Every type is either a @i<specific> type, a @i<class-wide> type, or a
-@i<universal> type. A specific type is one defined by a @fa<type_declaration>,
-a @fa<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:
-@dby
-Every type is one of a @i<specific> type, a @i<class-wide> type, or a
-@i<universal> type. A specific type is one defined by a @fa<type_declaration>,
-a @fa<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:
-
!corrigendum 3.8(18/2)
@drepl
@@ -457,20 +201,6 @@
of a named association in a discriminant constraint, in which case it is
evaluated once for each associated discriminant.
-!corrigendum 7.3.2(1/5)
-
-@dinsb
-For a private type, private extension, or interface, the following
-language-defined assertion aspects may be specified with an
-@fa<aspect_specification> (see 13.1.1):
-@dinst
-A type invariant is an assertion about the state of objects of a type exported
-by a package. The type invariant is enforced on objects used by clients of the
-package; it is generally not enforced on objects inside of the package.
-Similarly, a class-wide type invariant is an assertion of about the state of
-all objects of a class of types outside of the package defining the specific
-type of the class.
-
!corrigendum 7.3.2(5/5)
@drepl
@@ -496,40 +226,6 @@
the only operations that can be applied to this
current instance are those defined for such a formal derived type.
-!corrigendum 8.3(26/2)
-
-@drepl
-A non-overridable declaration is illegal if there is a homograph occurring
-immediately within the same declarative region that is visible at the place of
-the declaration, and is not hidden from all visibility by the non-overridable
-declaration. In addition, a type extension is illegal if somewhere within its
-immediate scope it has two visible components with the same name. Similarly,
-the @fa<context_clause> for a compilation unit is illegal if it mentions (in a
-@fa<with_clause>) some library unit, and there is a homograph of the library
-unit that is visible at the place of the compilation unit, and the homograph
-and the mentioned library unit are both declared immediately within the same
-declarative region. These rules also apply to dispatching operations declared
-in the visible part of an instance of a generic unit. However, they do not
-apply to other overloadable declarations in an instance; such declarations may
-have type conformant profiles in the instance, so long as the corresponding
-declarations in the generic were not type conformant.
-@dby
-A non-overridable declaration is illegal if there is a homograph occurring
-immediately within the same declarative region that is visible at the place of
-the declaration, and is not hidden from all visibility by the non-overridable
-declaration. In addition, a type extension is illegal if somewhere within its
-immediate scope it has two visible components with the same name. Similarly,
-the @fa<context_clause> for a compilation unit is illegal if it mentions (in a
-@fa<with_clause>) some library unit, and there is a homograph of the library
-unit that is visible at the place of the compilation unit, and the homograph
-and the mentioned library unit are both declared immediately within the same
-declarative region. These rules that apply to subprograms also apply to
-dispatching operations declared in the visible part of an instance of a
-generic unit. However, they do not apply to other overloadable declarations
-in an instance; such declarations may have type conformant profiles in the
-instance, so long as the corresponding declarations in the generic were not
-type conformant.
-
!corrigendum 10.2.1(18/3)
@drepl
@@ -557,150 +253,6 @@
accessible via access values from the parameters, are the same as they
were at the earlier call.>
-!corrigendum A.18.2(88.1/3)
-
-@drepl
-Vector'Write for a Vector object @i<V> writes Length(@i<V>) elements of the vector to the
-stream. It also may write additional information about the vector.
-@dby
-Vector'Write for a Vector object @i<V> writes Length(@i<V>) 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<L> writes Length(@i<L>) elements of the list to the
-stream. It also may write additional information about the list.
-@dby
-List'Write for a List object @i<L> writes Length(@i<L>) 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<M> writes Length(@i<M>) elements of the map to the
-stream. It also may write additional information about the map.
-@dby
-Map'Write for a Map object @i<M> writes Length(@i<M>) 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<S> writes Length(@i<S>) elements of the set to the
-stream. It also may write additional information about the set.
-@dby
-Set'Write for a Set object @i<S> writes Length(@i<S>) 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<T> writes Node_Count(@i<T>) - 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<T> writes Node_Count(@i<T>) - 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<The result of Is_Nul_Terminated is True if Item contains char16_nul,
-and is False otherwise.>
-@dby
-@xindent<The result of Is_Nul_Terminated is True if Item contains char32_nul,
-and is False otherwise.>
-
-!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 tests are needed for presentation changes; no semantic change is intended
@@ -782,23 +334,6 @@
****************************************************************
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 #32 - April 16, 2021
[Comment on 3.8(18/2).]
@@ -855,66 +390,6 @@
****************************************************************
From: Niklas Holsti
-WG 9 Review issue #148 - May 20, 2021
-
-[Comment on 7.3.2.]
-It might help readers if the intro were to explain that the aim of the
-Type_Invariant('Class) feature is to ensure that any object of this type/class
-satisfies the invariant when inspected or used by a client of the defining
-package, but the invariant does not have to be satisfied at each point within
-the operations of the defining package itself (where the full type declaration
-is visible). Therefore, the invariant is checked at the boundary between the
-defining package and its clients. Similar text is now in the Ramification
-RM 7.3.2 (23.a/5), but that is quite late in the section and is not visible
-in the non-annotated RM.
-
-****************************************************************
-
-From: Randy Brukardt
-WG 9 Review issue #148 - May 21, 2021
-
-This makes sense, but since the existing text (of which there is none!) is
-neither new nor wrong, this is out of bounds for this review. As such, it will
-be deferred. See issue #15 for more on this topic.
-
-****************************************************************
-
-From: Niklas Holsti
-WG 9 Review issue #150 - May 20, 2021
-
-[Comment on 8.3(26/2).]
-The paragraph starts by stating several rules for various things, and then
-says "These rules also apply to dispatching operators declared in the visible
-part of an instance of a generic unit". The part "these rules" is confusing,
-because some of the rules stated earlier in the paragraph apply to type
-extensions or to context clauses, neither of which seems relevant to
-declarations of dispatching operations. It seems that only the first rule
-stated in this paragraph, about non-overridable declarations, can apply to
-declarations of dispatching operations. It would be clearer to separate the
-rules for type extensions and context clauses into their own paragraphs (and,
-in the annotated RM, distribute the annotations accordingly).
-
-On second thought, perhaps the point about the dispatching operations is that
-such an operation could be the "homograph of the library unit" that is
-involved in the rule for context clauses. But at least the rule about type
-extensions seems irrelevant to dispatching operations.
-
-****************************************************************
-
-From: Randy Brukardt
-WG 9 Review issue #150 - May 21, 2021
-
-It's fairly clear from the AARM notes that both the first and third rules
-could apply to a dispatching operation (since compilation units can be a
-subprogram). And it is harmless (even if confusing) to apply the second rule
-in that case (it obviously only applies to types, so it doesn't ever trigger
-for a subprogram). As such, there is nothing actually wrong here, and this is
-old (Ada 2005) text. Thus this suggestion is out of bounds for this review and
-it is marked deferred. See issue #15 for more on this topic.
-
-****************************************************************
-
-From: Niklas Holsti
WG 9 Review issue #154 - May 20, 2021
[Comment on 9.2(7).]
@@ -1009,82 +484,3 @@
****************************************************************
-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: 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.
-
-****************************************************************
Questions? Ask the ACAA Technical Agent