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

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

!standard 10.2.1(2)          15-06-03 AI12-0417-1/01
!standard 10.2.1(3)
!standard 10.2.1(4)
!class Amendment 15-06-03
!status work item 15-06-03
!status received 15-03-20
!priority Low
!difficulty Easy
!subject Make categorization pragmas obsolescent
!summary
Obsolescence categorization pragmas, and make the aspects the primary definition.
!problem
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.
!proposal
(See Summary.)
!wording
** 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.]
!discussion
Note that 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).
!ASIS
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.)
!appendix

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 
Ada.Tags.

It seems quite hard to deduce that indeed a unit can be declared Pure by 
writing

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.

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


Questions? Ask the ACAA Technical Agent