Version 1.2 of ais/ai-00257.txt

Unformatted version of ais/ai-00257.txt version 1.2
Other versions for file ais/ai-00257.txt

!standard 13.12 (07)          01-02-12 AI95-00257/01
!class amendment 01-02-12
!status work item 01-02-12
!status received 01-02-12
!priority Low
!difficulty Easy
!subject Restrictions for implementation-defined entities
The following restrictions identifiers exist:
No_Implementation_Attributes No_Implementation_Pragmas No_Implementation_Restrictions
Ada code containing implementation-defined attributes, pragmas, and restrictions identifiers is much less portable than code that does not contain such items. However, it is difficult to prove that a given piece of Ada code does not contain any implementation-defined items. It can be accomplished by searching for the names of each possible implementation-defined entity, but this is error-prone and can be very time consuming if an implementation has many implementation-defined items.
We introduce additional restrictions identifiers to let the Ada processor do the checking for implementation-defined items.
The following restrictions identifiers are added:
No_Implementation_Attributes No_Implementation_Pragmas No_Implementation_Restrictions
[Open issues: Should these options be other than partition-wide? Note that pragma Restrictions is a configuration pragma, and 10.1.5(8) says that configuration pragmas are generally used to select a partition-wide or system-wide option.
Are pragmas, attributes, and restrictions defined by WG9-approved amendments implementation-defined or language-defined. I can think of good arguments either way? Perhaps an additional identifier: No_Amendments would be good idea.]
!ACATS test

From: Robert Dewar [dewar@GNAT.COM]
Sent: Tuesday, December 26, 2000 11:18 AM

Well a very important feature in GNAT that definitely should be
semi-standardized is

pragma Restrictions (No_Implementation_Attributes);

which would of course also disallow extensions to existing attributes

We also have

pragma Restrictions (No_Implementation_Pragmas);
pragma Restrictions (No_Implementation_REstrictions)

yes yes, I know the latter has to exclude itself :-)


From: Pascal Leroy
Sent: Wednesday, December 27, 2000 4:53 AM

These sound like very good ideas.


From: Robert A Duff
Sent: Tuesday, January 02, 2001 2:28 PM

Yes, that's a good idea.

Is it possible to turn it off in certain places?  I would like to be
able to say No_Implementation_Attributes on my whole program, but then
use impl-def attributes in one or two isolated places, by saying
"Yes_Implementation_Attributes" or some such thing in those places.


From: Robert Dewar
Sent: Tuesday, January 02, 2001 3:26 PM

Actually perhaps the best idea is to generalize this thought for *all*
restrictions pragmas???


From: Randy Brukardt
Sent: Tuesday, January 02, 2001 4:09 PM

Humm. Partition-wide restrictions make sense when they are used for runtime
tailoring (as suggested by Annex D), but when they are used to enforce
coding standards, certainly a method to allow exceptions would be very

It is specifically this reason (that we *don't* want it to be
partition-wide) that the pragma Explicit_Overridding is not a Restrictions
identifier, but rather is a separate configuration pragma.


From: Robert Dewar
Sent: Tuesday, January 02, 2001 7:00 PM

There is no requirement that restrictions pragmas have a partition wide
effect as a general rule.


From: Robert Dewar
Sent: Tuesday, January 02, 2001 10:04 PM

I really don't understand the argument here, there is simply no requirement
that all restrictions be partition wide, so why on earth was this used
as an argument that explicit overriding ccould not be a restriction?

From the RM:

<<8   A pragma Restrictions is a configuration pragma; unless otherwise
specified for a particular restriction, a partition shall obey the
restriction if a pragma Restrictions applies to any compilation unit included
in the partition.>>


From: Randy Brukardt
Sent: Tuesday, January 02, 2001 11:10 PM

You are quite right, I'm misremembering the RM here. Forget I brought up
that example.

Are there any Restrictions identifiers that aren't currently partition-wide?
I couldn't find one in a quick search of the RM.

In any case, the question is whether most of the restrictions defined in the
RM ought to have been partition-wide. It seems that they ought to be for
Annex D (for runtime selection), but not so obviously for Annex H or
"causal" use. And, if that decision was wrong, what we can do about it now?


Questions? Ask the ACAA Technical Agent