!standard D.2.6(9/5) 23-04-26 AI22-0058-1/03
!class Binding Interpretation 22-01-11
!status Corrigendum 1-2022 23-01-20
!status ARG Approved 15-0-0 23-01-19
!status work item 22-01-11
!status received 22-01-11
!subject Preconditions for checking Task_Ids
Preconditions, rather than wording, are used to check Task_Ids in various Annex D subprograms.
Ada 2022 attempts to use preconditions and postconditions as much as possible. The following rule appears in a number of places in Annex D:
For all the operations defined in <<some package>>, Tasking_Error is raised if the task identified by T has terminated. Program_Error is raised if the value of T is Null_Task_Id.
This would be better described by a precondition.
Add preconditions to various subprograms in Annex D.
with Pre => (T /= Null_Task_Id or else raise
(not Is_Terminated (T)
or else raise Tasking_Error));
to Set_Deadline, Get_Deadline, Set_Relative_Deadline, Get_Relative_Deadline, Get_Last_Release_Time in D.2.6(9/5); to Set_Priority in D.5.1(4); to Get_Priority in D.5.1(5); to Hold, Continue, and Is_Held in D.11(3/5); and to Clock in D.14(5/2).
Add use Ada.Task_Identification; on each of the above packages immediately after with Ada.Task_Identification;
In AARM D.5.1(12.a):
Replace "the above rule saying" with "the precondition".
Delete D.2.6(29/2), D.5.1(9), D.11(8).
The function Clock returns the current execution time of the task identified by T[; Tasking_Error is raised if that task has terminated; Program_Error is raised if the value of T is Task_Identification.Null_Task_Id].
The original English-language rule is backwards – one has to check for Null_Task_Id before checking whether a task is terminated.
Ada.Task_Identification.Is_Terminated is defined to raise Program_Error when passed a Null_Task_Id (see C.7.1), so we would not need to handle that case explicitly. We did so anyway to make the function of the precondition as clear as possible. Thus, this makes no semantic change (assuming a sensible reading of the original text).
[Editor's note: Since this makes no semantic change, it is classified as a Binding Interpretation. It could even be considered a presentation change, except that this does open the possibility of Suppressing the precondition check. Note, however, that there is no check name defined for the packages defined in the various annexes (that seems to be an omission, but one that should be considered on its own merits in a separate AI).]
No semantic change is intended, so existing tests (if they exist) should cover this case.
This AI was promoted from AI12-0316-1 to be reconsidered for post-Ada 2022 work. The !appendix of the original AI has additional motivation and discussion.
The first version of this AI was rewritten to use the suggestion from Randy Brukardt of February 26, 2019 to simplify the change and overcome objections raised during Meeting #60D.