Version 1.4 of ai12s/ai12-0417-1.txt
!standard 10.2.1(2) 20-12-08 AI12-0417-1/01
!class Amendment 20-12-08
!status Amendment 1-2012 21-01-21
!status ARG Approved 16-0-0 21-01-20
!status work item 20-12-08
!status received 20-09-29
!subject Make categorization pragmas obsolescent
Obsolesce categorization pragmas, and make the aspects the primary
Various AIs, culminating in AI12-0414-1, have replaced all categorization
pragmas in the RM with categorization aspects. Ada 2012 already replaced
and obsolesced most of the other pragmas that apply to entities.
However, the categorization pragmas are still defined as the primary
definition of that concept. It's not obvious from the current wording
that one can use these categorizations as aspects.
** TBD **
[Editor's note: I didn't work out the detailed wording changes, as they
should be fairly obvious, and I didn't want to spend the time until we've
discussed whether to do this at all.
Note that we need to change both 10.2.1 and E.2 if we do this, as well as
create one or more new J.15 subclauses.
John also raised the interesting question of whether we still need the
definitions of "program unit pragmas" and "library unit pragmas" in 10.1.5,
or whether that too should move to Annex J. I haven't checked if any of
these still remain in the core or annexes.]
Pragma Preelaborable_Initialization has already made the trip to Annex J.
It makes sense for the related Preelaboration and Pure pragmas to follow.
This is really a presentation change. There is no (required) effect on
implementations of this change. It is implementation-defined whether
No_Obsolescent_Features applies to obsolescent pragmas, so an implementation
does not even need to change the implementation of that restriction (it can
if it wants, of course).
No ASIS effect.
No ACATS tests are needed. (It is implementation-defined whether
No_Obsolescent_Features applies to obsolescent pragmas, and thus it is not
From the AARM Review of John Barnes.
10.2.1 Elaboration Control
I thought that the description was going to be changed so that aspects such as
Pure would usually be set by an aspect rather than a pragma. It seems topsy
turvy therefore to introduce pragmas such as Pure here still. Should we not
be introducing the concepts here and the use of aspects and then the pragmas
themselves should be in an annex? A lot of predefined units now show
preelaborate in a list of aspects (when adding nonblocking I think). Eg
It seems quite hard to deduce that indeed a unit can be declared Pure by
with Pure is
I believe that it was thought that I was against using Pure as in
with Pure is
What I disliked is the juxataposition is end. It occurs in
System.Atomic_Operations in C.6.1. Never mind.
It also occurs with generic signatures. I grumble about it on page 496 of
I don't think it could happen in Ada 83. It might have happened with tasks
that had no entries, but the abbreviation
task T is
was introduced. And of course Ada 83 did not have children so a Package
without any subprograms was a bit pointless.
Anyway, enough of this ranting, I will turn to Exceptions.
10.1.5 I am surprised that there are no changes in the
discussion on pragmas. It is probably OK since this discusses only
certain pragmas and not pragmas as a whole. Maybe there should be a
cross reference to the use of pragmas for setting aspects.
Questions? Ask the ACAA Technical Agent