CVS difference for ai22s/ai22-0001-1.txt
--- ai22s/ai22-0001-1.txt 2021/11/19 07:42:35 1.2
+++ ai22s/ai22-0001-1.txt 2022/01/08 05:42:02 1.3
@@ -1,4 +1,4 @@
-!standard 3.9(21) 21-11-18 AI22-0001-1/02
+!standard 3.9(21) 22-01-07 AI22-0001-1/03
!standard 3.9.3(8/3)
!standard 4.2.1(7/5)
!standard 4.3.5(7/5)
@@ -7,7 +7,7 @@
!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 deleted 21-01-19
!status work item 21-11-11
!status received 21-07-14
!priority Low
@@ -16,375 +16,23 @@
!subject Presentation issues in Ada 202x submission
!summary
-Various presentation issues which have no effect on semantics are fixed.
+This AI was renumbered as AI12-0437-1 so it applies to the Ada 202x documents.
!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)
-
-@drepl
-The type of an @fa<aggregate>, or of an object created by an @fa<object_declaration>
-or an @fa<allocator>, or a generic formal object of mode @b<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 @fa<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.
-@dby
-The type of an @fa<aggregate>, of an object created by an @fa<object_declaration>
-or an @fa<allocator>, or of a generic formal object of mode @b<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 @fa<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)
-
-@drepl
-The @i<procedure_>@fa<name> specified for Add_Unnamed for an Aggregate
-aspect shall denote a procedure that has two parameters, the first an
-@b<in out> parameter of the container type, and the second an @b<in>
-parameter of some nonlimited type, called the @i<element type> of the
-container type.
-@dby
-The @i<procedure_>@fa<name> specified for Add_Unnamed for an Aggregate
-aspect shall denote exactly one procedure that has two parameters, the first
-an @b<in out> parameter of the container type, and the second an @b<in>
-parameter of some nonlimited type, called the @i<element type> of the
-container type.
-
-!corrigendum 4.3.5(8/5)
-
-@drepl
-The @i<function_>@fa<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 @i<key type> of the container type.
-@dby
-The @i<function_>@fa<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 @i<key type> of the container type.
-
-!corrigendum 4.3.5(9/5)
-
-@drepl
-The @i<procedure_>@fa<name> specified for Add_Named or Assign_Indexed for an
-Aggregate aspect
-shall denote a procedure that has three parameters, the first an @b<in out>
-parameter of the container type, the second an @b<in> parameter of a nonlimited
-type (the @i<key type> of the container type), and the third, an @b<in>
-parameter of a nonlimited type that is called the @i<element type> of the
-container type.
-@dby
-The @i<procedure_>@fa<name> specified for Add_Named or Assign_Indexed for an
-Aggregate aspect shall denote exactly one procedure that has three parameters,
-the first an @b<in out> parameter of the container type, the second an @b<in>
-parameter of a nonlimited type (the @i<key type> of the container type), and
-the third, an @b<in> parameter of a nonlimited type that is called the
-@i<element type> of the container type.
-
-
-!corrigendum 4.3.5(22/5)
-
-@drepl
-The expected type for a @fa<container_aggregate> shall be a type for which
-the Aggregate aspect has been specified. The expected type for each
-@fa<expression> of a @fa<container_aggregate> is the element type of the expected
-type.
-@dby
-The expected type for a @fa<container_aggregate> shall be a single type for which
-the Aggregate aspect has been specified. The expected type for each
-@fa<expression> of a @fa<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