Version 1.4 of ai12s/ai12-0417-1.txt

Unformatted version of ai12s/ai12-0417-1.txt version 1.4
Other versions for file ai12s/ai12-0417-1.txt

!standard 10.2.1(2)          20-12-08 AI12-0417-1/01
!standard 10.2.1(3)
!standard 10.2.1(4)
!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
!priority Low
!difficulty Easy
!subject Make categorization pragmas obsolescent
Obsolesce categorization pragmas, and make the aspects the primary definition.
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.
(See Summary.)
** 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.
!ACATS test
No ACATS tests are needed. (It is implementation-defined whether No_Obsolescent_Features applies to obsolescent pragmas, and thus it is not usefully testable.)

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 

package Pig
       with Pure is

I believe that it was thought that I was against using Pure as in

package Ada 
     with Pure is
end Ada;

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 
my book.

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;

rather than

task T is
end T;

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