Version 1.1 of ai05s/ai05-0241-1.txt
!standard 13.12.1(0) 11-02-09 AI05-0241-1/01
!class Amendment 11-02-09
!status work item 11-02-09
!status received 11-01-24
!priority Low
!difficulty Low
!subject Aspect-related restrictions
!summary
Two aspect-related restrictions are defined:
pragma Restrictions(No_Implementation_Aspects);
pragma Restrictions(No_Aspect_Specification => <aspect-identifier>);
!problem
Given the new aspect_specification syntax, it is important to provide a way to
forbid implementation-defined ones, analogous to No_Implementation_Attributes
and No_Implementation_Pragmas. Also, it is important to provide a way to forbid
the specification of particular aspects, analogous to No_Dependence.
!proposal
See wording.
!wording
Add after 13.12.1(1/2):
No_Implementation_Aspects
There are no implementation-defined aspects, attributes, pragmas,
or pragma arguments. This restriction applies only to the current
compilation or environment, not the entire partition.
AARM note:
Discussion: This restriction (as well as others below) applies only
to the current compilation, because it is likely that the runtime
(and possibly user-written low-level code) will need to use
implementation-defined aspects. But a partition-wide restriction
applies everywhere, including the runtime.
Delete 13.12.1(2.a/2), which is subsumed by the above AARM "Discussion".
Modify 13.12.1(5/2):
The following restriction_parameter_identifier{s are} [is] language defined:
Add after 13.12.1(5/2):
No_Aspect_Specification
Specifies an aspect that is not specified, either by an
aspect_specification, an attribute_definition_clause, or a
pragma.
Legality Rules
The restriction_parameter_argument of a No_Aspect_Specification restriction
shall be an identifier; this identifier does not denote any declaration.
AARM note:
Ramification: This restriction_parameter_argument is not resolved.
As for No_Dependence, there is no check that the aspect identifier is
meaningful; it might refer to an implementation-defined aspect on one
implementation, but nothing at all on another implementation. Of course,
a good implementation will warn if the aspect is unknown to it.
!discussion
The need for No_Implementation_Aspects follows directly from the existence of
No_Implementation_Attributes and No_Implementation_Pragmas.
The need for No_Aspect_Specification came up during the discussion of subtype
predicates (see AI05-0153-3). Some people are uncomfortable with the rather
leaky-colander-like semantics of Dynamic_Predicate in particular, so there
should be a way to self-impose a restriction forbidding the specification of
this aspect on some projects. Rather than invent a particular restriction for
that purpose, it seems obviously cleaner to have a general-purpose restriction
that can be used with any aspect. The history leading to No_Dependence affirms
the wisdom of this choice.
Note that No_Implementation_Aspects forbids specification of relevant aspects
via any means. For those aspects that correspond to attributes, it also forbids
queries. In contrast, No_Aspect_Specification does not forbid queries.
Note that No_Aspect_Specification can be used for both language-defined and
implementation-defined aspects.
!example
pragma Restrictions(No_Implementation_Aspects);
pragma Restrictions(No_Aspect_Specification => Dynamic_Predicate);
!ACATS test
Add ACATS B and C tests for this feature.
!appendix
From: Robert Dewar
Sent: Monday, July 26, 2010 7:46 PM
Implementations are allowed to add grandchildren to Ada etc. And GNAT
takes advantage of this, e.g. to add the encoding packages to earlier
versions of Ada.
But this creates portability problems, we should really have a
restriction to prevent this, in the style of No_Implementation_Pragmas.
How about No_Implementation_Units
?
I am not really suggesting a new AI at this stage, just some guidance
on whether this is a good idea so that implementations can adopt it
(and then we can put it into Ada 2019 :-))
****************************************************************
From: Tucker Taft
Sent: Monday, July 26, 2010 8:14 PM
This sounds like a very good idea.
Users are often confused about what
packages are "standard" Ada and what
are not.
Does this also cover System.* and Interfaces.*?
One rule might be to disallow any package that starts with "Ada", "System",
or "Interfaces" that is not in the reference manual. These are the ones
that confuse users.
****************************************************************
From: Robert Dewar
Sent: Monday, July 26, 2010 8:33 PM
Right, that's what I had in mind.
And the idea would be in particular to forbid use of RM packages in an
inappropriately earlier version of Ada (e.g. using the string encoding packages
in Ada 2005 mode). Of course I know that can't be part of the standard, but
that would be the encouraged usage (and is what GNAT intends to do).
****************************************************************
From: Bob Duff
Sent: Monday, January 24, 2011 9:52 AM
> P.S. should we have a restriction
>
> No_Implementation_Aspects
Yes, good idea.
****************************************************************
From: Bob Duff
Sent: Monday, January 24, 2011 10:02 AM
By the way, obviously some folks would like to forbid Dynamic_Predicate, so
there should be a restriction for that. Instead of doing it piecemeal, we
should do like we did for No_Dependence, and have a general feature for
forbidding any aspect. Something like:
pragma Restrictions (No_Aspect => Dynamic_Predicate);
We could have an enum type somewhere that lists all the aspect names. Or we
could just allow an "aspect_identifier" there, without involving visibility --
like pragma arguments. For aspects that are also attributes or pragmas, the
restriction should forbid both forms.
I've got no problem with self-imposed or project-imposed restrictions! If,
someday, some customer requests No_Evil_Predicates, I expect AdaCore would
implement it (if we can come up with a coherent definition of "evil").
****************************************************************
From: Tucker Taft
Sent: Monday, January 24, 2011 10:19 AM
Or perhaps something like:
pragma Restrictions(No_Aspect_Specification => Dynamic_Predicate);
to be analogous to "No_Dependence => ...".
****************************************************************
From: Bob Duff
Sent: Monday, January 24, 2011 10:38 AM
Yes, that's better. For those aspects that are also attributes, you probably
want to restrict the specification, but not the query.
****************************************************************
From: Robert Dewar
Sent: Tuesday, January 25, 2011 6:14 AM
> Or perhaps something like:
>
> pragma Restrictions(No_Aspect_Specification =>
> Dynamic_Predicate);
>
> to be analogous to "No_Dependence => ...".
Can't we just have
No_Aspect => name
I see no advantage to reader or writer in adding the Specification part here,
especially if it also bans a corresponding pragma or attribute.
****************************************************************
From: Robert Dewar
Sent: Tuesday, January 25, 2011 6:15 AM
> Yes, that's better. For those aspects that are also attributes, you
> probably want to restrict the specification, but not the query.
>
>> to be analogous to "No_Dependence => ...".
OK, I see, grumble, I guess the long name will have to do
****************************************************************
Questions? Ask the ACAA Technical Agent