Version 1.1 of ai12s/ai12-0294-1.txt

Unformatted version of ai12s/ai12-0294-1.txt version 1.1
Other versions for file ai12s/ai12-0294-1.txt

!standard 3.3(23/3)          18-11-15 AI12-0294-1/01
!standard 5.5.3(20/5)
!class Amendment 18-11-15
!status Amendment 1-2012 18-11-15
!status work item 18-11-15
!status received 18-10-21
!priority Low
!difficulty Easy
!subject More clean-ups for Ada 2020
!summary
[Editor's note: These cleanups have already been applied to the draft Standard.]
Various minor issues are corrected:
(1) Accept statements are banned in the body of a procedural iterator loop.
(2) Wording involving the nominal subtype of an object is improved.
!problem
Various minor issues, mostly caused by other Amendment AIs, are repaired.
(1) 5.5.3 (from AI12-0189-1) allows accept statements in the body of a procedural iterator loop. However, such accept statements would be illegal if the loop was written manually (as 9.5.2(14) would be violated.
(2) 3.3(23/3) contains the following sentence:
"The object's actual subtype (that is, its subtype) can be more restrictive than the nominal subtype of the view; it always is if the nominal subtype is an indefinite subtype."
The middle "is" in this sentence is hanging and it's unclear to what it refers. This should be clarified.
!proposal
(See Summary.)
!wording
(1) Add after 5.5.3(20/5) [from AI12-0189-1]:
The sequence_of_statements of a loop_statement with a procedural_iterator as its iteration_scheme shall not contain an accept_statement.
AARM Reason: An accept_statement is not allowed in a procedure (see 9.5.2), it has to be directly in a task_body. Since the loop body here is implemented as a procedure, we can't allow accept_statements there, either, even if the loop itself is directly in a task_body.
AARM Ramification: This includes cases where the accept_statement is part of another construct, for instance, a select_statement.
(2) Modify 3.3(23/3):
The object's actual subtype (that is, its subtype) can be more restrictive than the nominal subtype of the view; it always is {more restrictive} if the nominal subtype is an indefinite subtype.
!discussion
(1) As noted in the problem, 9.5.2(14) would make an accept statement illegal in a procedure, if the loop was written explicitly. Of course, that's true for exit and goto as well, and we require those to be implemented. But those terminate the iteration, while an accept statement would not have that effect. So supporting that would complicate the implementation for no obvious benefit. Therefore, we ban then unconditionally in this case.
(2) This wording goes back to the 2.0 version of Ada 9x (that is, the first version with actual wording), so fixing it isn't a priority.
However, the original question arose from an ARG member who though that "as" was missing from this text. The resulting sentence would violate the Dewar rule (surely not all nominal subtypes are indefinite). The author then spent a substantial amount of time trying to figure out a meaning that doesn't violate the Dewar rule.
A normal reader shouldn't have to apply the Dewar rule to be able to read the RM, thus we clarify the sentence. No change in meaning is intended.
!corrigendum 3.3(23/3)
Replace the paragraph:
At the place where a view of an object is defined, a nominal subtype is associated with the view. The object's actual subtype (that is, its subtype) can be more restrictive than the nominal subtype of the view; it always is if the nominal subtype is an indefinite subtype. A subtype is an indefinite subtype if it is an unconstrained array subtype, or if it has unknown discriminants or unconstrained discriminants without defaults (see 3.7); otherwise, the subtype is a definite subtype (all elementary subtypes are definite subtypes). A class-wide subtype is defined to have unknown discriminants, and is therefore an indefinite subtype. An indefinite subtype does not by itself provide enough information to create an object; an additional constraint or explicit initialization expression is necessary (see 3.3.1). A component cannot have an indefinite nominal subtype.
by:
At the place where a view of an object is defined, a nominal subtype is associated with the view. The object's actual subtype (that is, its subtype) can be more restrictive than the nominal subtype of the view; it always is more restrictive if the nominal subtype is an indefinite subtype. A subtype is an indefinite subtype if it is an unconstrained array subtype, or if it has unknown discriminants or unconstrained discriminants without defaults (see 3.7); otherwise, the subtype is a definite subtype (all elementary subtypes are definite subtypes). A class-wide subtype is defined to have unknown discriminants, and is therefore an indefinite subtype. An indefinite subtype does not by itself provide enough information to create an object; an additional constraint or explicit initialization expression is necessary (see 3.3.1). A component cannot have an indefinite nominal subtype.
!comment The following is mainly to force a conflict.
!corrigendum 5.5.3(0)
Insert after the paragraph:
The sequence_of_statements of a loop_statement with a procedural_iterator as its iteration_scheme shall contain an exit_statement, return statement, goto_statement, or requeue_statement that leaves the loop only if the callable entity C associated with the procedural_iterator has an Allows_Exit aspect specified True.
the new paragraph:
The sequence_of_statements of a loop_statement with a procedural_iterator as its iteration_scheme shall not contain an accept_statement.
!ASIS
No changes needed.
!ACATS test
An ACATS B-Test is needed for (1). No test is needed for (2).
!appendix

****************************************************************


Questions? Ask the ACAA Technical Agent