Version 1.2 of ai22s/ai22-0001-1.txt
!standard 3.9(21) 21-11-18 AI22-0001-1/02
!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)
!class presentation 21-11-11
!status ARG Approved 13-0-0 21-11-18
!status work item 21-11-11
!status received 21-07-14
!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.
!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.)
!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: The addition to the index has already been done to the
current working draft.]
(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 ...
!discussion
Overall: all of these fixes are just presentation changes that ought to have
no semantic effect. They could be treated as "typos" (using an expansive
definition of that) and fixed in the final version of the Ada 202x documents.
[Editor asks: should we do that???]
(1) This is a typo that can be fixed in the final version of the Ada 202x
document. [Editor's note: We plan to do that, so it doesn't need to appear in
any future Corrigendum.]
(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.
!corrigendum 3.9.3(8/3)
Replace the paragraph:
The type of an aggregate, or of an object created by an object_declaration
or an allocator, or a generic formal object of mode in, 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 return_subtype_indication (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.
by:
The type of an aggregate, 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 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 return_subtype_indication (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.3.5(7/5)
Replace the paragraph:
The procedure_name specified for Add_Unnamed for an Aggregate
aspect shall denote 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.
by:
The procedure_name specified for Add_Unnamed for an Aggregate
aspect shall denote exactly one 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.
!corrigendum 4.3.5(8/5)
Replace the paragraph:
The function_name specified for New_Indexed for an
Aggregate aspect shall denote
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.
by:
The function_name specified for New_Indexed for an
Aggregate aspect shall denote exactly one 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.
!corrigendum 4.3.5(9/5)
Replace the paragraph:
The procedure_name specified for Add_Named or Assign_Indexed for an
Aggregate aspect
shall denote 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.
by:
The procedure_name specified for Add_Named or Assign_Indexed for an
Aggregate aspect shall denote exactly one 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.
!corrigendum 4.3.5(22/5)
Replace the paragraph:
The expected type for a container_aggregate shall be a 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.
by:
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.
!ACATS test
No ACATS tests needed for presentation changes.
!appendix
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: 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.]
****************************************************************
Questions? Ask the ACAA Technical Agent