Version 1.1 of ai12s/ai12-0417-1.txt
!standard 10.2.1(2) 15-06-03 AI12-0417-1/01
!class Amendment 15-06-03
!status work item 15-06-03
!status received 15-03-20
!subject Make categorization pragmas obsolescent
Obsolescence 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 obsolescenced 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.]
Note that pragma Preelaborable_Initialization has already made the trip to
Annex J. It makes sense for the related Preelaboration and Pure pragmas to
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.
Questions? Ask the ACAA Technical Agent