13.1.1 Aspect Specifications
{
AI05-0183-1}
[Certain representation or operational aspects of an entity may be specified
as part of its declaration using an
aspect_specification,
rather than using a separate representation or operational item.] The
declaration with the
aspect_specification
is termed the
associated declaration.
Syntax
Language Design Principles
{
AI05-0183-1}
{
AI05-0267-1}
The
aspect_specification
is an optional element in most kinds of declarations. Here is a list
of all kinds of declarations and an indication of whether or not they
allow aspect clauses, and in some cases a short discussion of why (*
= allowed, NO = not allowed). Kinds of declarations with no indication
are followed by their subdivisions (which have indications).
{
AI05-0267-1}
Syntactically,
aspect_specifications
generally are located at the end of declarations. When a declaration
is all in one piece such as a
null_procedure_declaration,
object_declaration,
or
generic_instantiation
the
aspect_specification
goes at the end of the declaration; it is then more visible and less
likely to interfere with the layout of the rest of the structure. However,
we make an exception for program units (other than subprogram specifications)
and bodies, in which the
aspect_specification
goes before the
is. In these cases, the entity could be large
and could contain other declarations that also have
aspect_specifications,
so it is better to put the
aspect_specification
toward the top of the declaration. (Some aspects – such as Pure
– also affect the legality of the contents of a unit, so it would
be annoying to only see those after reading the entire unit.)
Name Resolution Rules
{
AI05-0183-1}
{
AI12-0212-1}
An
aspect_mark
identifies an aspect of the entity defined by the associated declaration
(the
associated entity); the aspect denotes
an object, a value, an expression, an
aggregate,
a subprogram, or some other kind of entity. If the
aspect_mark
identifies:
an aspect that denotes an object, the
aspect_definition
shall be a
name.
The expected type for the
name
is the type of the identified aspect of the associated entity;
an aspect that is a value or an expression, the
aspect_definition
shall be an
expression.
The expected type for the
expression
is the type of the identified aspect of the associated entity;
Ramification: {
AI12-0212-1}
The only requirement here is that the
expression
is syntactically an
aggregate;
there is no requirement that it resolve to some particular type or even
that it should resolve like an
aggregate.
Each aspect that uses an
aggregate
is responsible for specifying how the choice(s), component(s), and other
contents of the
aggregate
are resolved and interpreted.
an aspect that denotes a subprogram, the
aspect_definition
shall be a
name;
the expected profile for the
name
is the profile required for the aspect of the associated entity;
an aspect that denotes some other kind of entity,
the
aspect_definition
shall be a
name,
and the name shall resolve to denote an entity of the appropriate kind;
an aspect that is given by an identifier specific
to the aspect, the
aspect_definition
shall be an
identifier,
and the
identifier
shall be one of the identifiers specific to the identified aspect.
{
AI05-0183-1}
{
AI12-0373-1}
The usage names in an
aspect_definition
[ are not resolved at the point of the associated declaration, but rather]
are resolved at the end of the immediately enclosing declaration list,
or in the case of the declaration of a library unit, at the end of the
visible part of the entity.
{
AI05-0183-1}
{
AI12-0180-1}
{
AI12-0220-1}
If the associated declaration is for a subprogram, entry, or access-to-subprogram
type, the names of the formal parameters are directly visible within
the
aspect_definition,
as are certain attributes, as specified elsewhere in this International
Standard for the identified aspect. If the associated declaration is
a
type_declaration,
within the
aspect_definition
the names of any visible components, protected subprograms, and entries
are directly visible, and the name of the first subtype denotes the current
instance of the type (see
8.6). If the associated
declaration is a
subtype_declaration,
within the
aspect_definition
the name of the new subtype denotes the current instance of the subtype.
Legality Rules
{
AI05-0183-1}
If the first freezing point of the associated entity comes before the
end of the immediately enclosing declaration list, then each usage name
in the
aspect_definition
shall resolve to the same entity at the first freezing point as it does
at the end of the immediately enclosing declaration list.
{
AI05-0183-1}
At most one occurrence of each
aspect_mark
is allowed within a single
aspect_specification.
The aspect identified by the
aspect_mark
shall be an aspect that can be specified for the associated entity (or
view of the entity defined by the associated declaration).
Ramification: {
AI12-0116-1}
This rule prevents multiple specifications in the same
aspect_specification.
Rules in
13.1 prevent multiple specifications
in different
aspect_specifications
(on different views of the same type, for instance) or between operational
or representation items and an
aspect_specification,
even for aspects that are neither operational nor representation aspects.
{
AI05-0183-1}
If the
aspect_mark
includes 'Class, then the associated entity shall be a tagged type or
a primitive subprogram of a tagged type.
Discussion: {
AI12-0064-2}
Implementation-defined aspects can be allowed on these, of course; the
implementation will need to define the semantics. In addition, the language
does not define default aspect matching rules for generic formals; only
the handful of aspects allowed on formals have such rules. Therefore,
the implementation will need to define actual type matching rules for
any aspects allowed on formal types.
Reason: Most language-defined aspects
(for example, preconditions) are intended to be available to callers,
and specifying them on a body that has a separate declaration hides them
from callers. Specific language-defined aspects may allow this, but they
have to do so explicitly (by defining an alternative Legality Rule),
and provide any needed rules about visibility. Note that this rule does
not apply to implementation-defined aspects, so implementers need to
carefully define whether such aspects can be applied to bodies and stubs,
and what happens if they are specified on both the declaration and body
of a unit.
{
AI05-0183-1}
{
AI12-0138-1}
{
AI12-0374-1}
If an aspect of a derived type (or its first subtype) is inherited from
an ancestor (sub)type and has the boolean value True, the inherited value
shall not be overridden to have the value False for the derived type
(or its first subtype), unless otherwise specified in this International
Standard. If an aspect of a nonfirst subtype is inherited from the subtype
in the
subtype_indication
that defines it, and has the value True, the inherited value shall not
be overridden to have the value False for the nonfirst subtype, unless
otherwise specified in this International Standard.
{
AI12-0138-1}
{
AI12-0206-1}
{
AI12-0211-1}
If a nonoverridable aspect is directly specified for a type
T,
then any explicit specification of that aspect for any descendant of
T (other than
T itself) shall be
confirming.
In the case of an aspect whose value is a
name,
this means that the specified
name
shall
match the inherited aspect in the sense
that it shall denote the same declarations as would the inherited
name.
{
AI12-0138-1}
If a full type has a partial view, and a given nonoverridable aspect
is allowed for both the full view and the partial view, then the given
aspect for the partial view and the full view shall be the same: the
aspect shall be directly specified only on the partial view; if the full
type inherits the aspect, then a matching definition shall be specified
(directly or by inheritance) for the partial view.
Ramification: In order to enforce these
rules without breaking privacy, we cannot allow a private type that could
have a particular overridable aspect to have a hidden definition of that
aspect. There is no problem if the private type does not allow the aspect
(as the aspect could not be specified on descendants in that case).
{
AI12-0211-1}
If a type inherits a nonoverridable aspect from multiple ancestors, the
value of the aspect inherited from any given ancestor shall be confirming
of the values inherited from all other ancestors.
Reason: {
AI12-0005-1}
{
AI12-0211-1}
If more than one progenitor of a type
T specifies a nonoverridable
aspect, they all have to specify the same or matching values for that
aspect. Otherwise, we'd have two different values for the aspect that
depend on the view of the type; that would violate the definition of
type aspects being the same for all views of a type.
{
AI12-0138-1}
{
AI12-0211-1}
In addition to the places where Legality Rules normally
apply (see
12.3), these rules about nonoverridable
aspects also apply in the private part of an instance of a generic unit.
{
AI12-0138-1}
{
AI12-0206-1}
{
AI12-0256-1}
{
AI12-0373-1}
[The Default_Iterator, Iterator_Element, Implicit_Dereference, Constant_Indexing,
Variable_Indexing, Aggregate, Max_Entry_Queue_Length, and No_Controlled_Parts
aspects are nonoverridable.]
Discussion: We don't need an assume-the-worst
rule for most nonoverridable aspects as they only work on tagged types
and deriving from formal tagged types is not allowed in generic bodies.
In the case of Implicit_Dereference, a derivation in a generic body does
not cause problems (the ancestor necessarily cannot have the aspect,
else specifying the aspect would be illegal), as there could be no place
with visibility on both aspects. In the case of Max_Entry_Queue_Length,
it is only allowed on task and protected types, and on entries, and there
are not formal versions of any of those things. In the case of No_Controlled_Parts,
we defined an assume-the-worst rule with the aspect.
Static Semantics
a
name
that denotes a subprogram, object, or other kind of entity;
an
expression,
which is either evaluated to produce a single value, or which (as in
a precondition) is to be evaluated at particular points during later
execution; or
{
AI05-0183-1}
The identified aspect of the associated entity, or in some cases, the
view of the entity defined by the declaration, is as specified by the
aspect_definition
(or by the default of True when boolean). Whether an
aspect_specification
applies to an entity or only to the particular view of the entity
defined by the declaration is determined by the
aspect_mark
and the kind of entity. The following aspects are view specific:
{
AI05-0183-1}
All other
aspect_specifications
are associated with the entity, and
apply to all views of the
entity, unless otherwise specified in this International Standard.
if the associated entity is a tagged type, the
specification
applies to all descendants of the type;
if the associated entity is a primitive subprogram
of a tagged type
T, the specification
applies to the corresponding
primitive subprogram of all descendants of
T.
{
AI12-0005-1}
Unless specified otherwise, all of the requirements for specifying a
particular aspect with an
attribute_definition_clause
also apply to an
aspect_specification
for the aspect. These are enforced at the freezing point of the entity.
For example, when specifying the Size aspect of a subtype, the expression
has to be a static expression with an integer type and a nonnegative
value, all of the recommended level of support requirements apply if
Annex C is supported (see
C.2),
and so on.
{
AI05-0229-1}
{
AI12-0154-1}
Any aspect specified by a representation pragma or library unit pragma
that has a
local_name
as its single argument may be specified by an
aspect_specification,
with the entity being the
local_name.
The
aspect_definition
is expected to be of type Boolean. The expression shall be static. Notwithstanding
what this International Standard says elsewhere, the expression of an
aspect that can be specified by a library unit pragma is resolved and
evaluated at the point where it occurs in the
aspect_specification[,
rather than the first freezing point of the associated package].
Ramification: The name of the aspect
is the same as that of the pragma (see
13.1),
so the
aspect_mark
is the name of the pragma.
{
AI05-0229-1}
In addition, other operational and representation aspects not associated
with specifiable attributes or representation pragmas may be specified,
as specified elsewhere in this International Standard.
Reason: Some rules only apply when an
aspect has been specified (for instance, an indexable type is one that
has aspect Variable_Indexing specified). In order to prevent privacy
breaking, this can only be true when the specification of the aspect
is visible. In particular, if the Variable_Indexing aspect is specified
on the full view of a private type, the private type is not considered
an indexable type.
{
AI05-0183-1}
Alternative legality and semantics rules may apply for particular aspects,
as specified elsewhere in this International Standard.
Dynamic Semantics
{
AI05-0183-1}
At the freezing point of the associated entity, the
aspect_specification
is elaborated. The elaboration of the
aspect_specification
includes the evaluation of the
name
or
expression,
if any, unless the aspect itself is an expression. If the corresponding
aspect represents an expression (as in a precondition), the elaboration
has no effect; the expression is evaluated later at points within the
execution as specified elsewhere in this International Standard for the
particular aspect.
Implementation Permissions
{
AI05-0183-1}
Implementations may support implementation-defined aspects. The
aspect_specification
for an implementation-defined aspect may use an implementation-defined
syntax for the
aspect_definition,
and may follow implementation-defined legality and semantics rules.
Discussion: The intent is to allow implementations
to support aspects that are defined, for example, by a
subtype_indication
rather than an
expression
or a
name.
We chose not to try to enumerate all possible
aspect_definition
syntaxes, but to give implementations maximum freedom. Unrecognized aspects
are illegal whether or not they use custom syntax, so this freedom does
not reduce portability.
Implementation defined: Implementation-defined
aspects, including the syntax for specifying such aspects and the legality
rules for such aspects.
Extensions to Ada 2005
Inconsistencies With Ada 2012
{
AI12-0180-1}
Correction: Names of protected subprograms
and entries are now directly visible in an aspect of a type declaration.
This was always intended to be the case, but it was omitted from the
Standard by an editing error. In the unlikely case that a parameterless
protected function has the same name and type as an entity used in a
type invariant expression, the meaning would change from the outside
entity which would now be hidden by the protected function. It is much
more likely that a conflict (itself rather unlikely) would cause a resolution
failure.
Incompatibilities With Ada 2012
{
AI12-0154-1}
Corrigendum: Added a clarification that aspects
that correspond to library unit pragmas are resolved and evaluated immediately.
This is incompatible, as a reference to an entity defined after the aspect
will now be illegal. However, this would have required retroactive enforcement
of such aspects, which is a new capability not available from the associated
pragma, and moreover no known Ada 2012 implementation has ever allowed
late evaluation of such aspects. As such, there should be no practical
incompatibility.
{
AI12-0220-1}
Parameters of access-to-subprogram types are now visible in aspect specifications.
This can be incompatible if some entity with the same name as a parameter
is used in an existing aspect specification. We believe that all such
aspects require either static expressions or statically denoting of a
subprogram; since a parameter can be neither of these and hides everything
else, all such cases will be caught at compile-time. In addition, we
expect such cases to be very rare.
Extensions to Ada 2012
{
AI12-0212-1}
An aspect can be an unresolved
aggregate,
these can be used to specify a list of entities, or to set a group of
different but related properties with a single aspect.
Wording Changes from Ada 2012
{
AI12-0105-1}
Corrigendum: Clarified the wording so that the restriction against
language-defined aspects on subprogram completions includes completions
that are expressions functions and null procedures.
{
AI12-0138-1}
Corrigendum: Added a definition of nonoverridable aspects. This
is necessary to prevent generic contract problems with formal derived
types.
{
AI12-0206-1}
Correction: Extended the definition of nonoverridable aspects
to cover most kinds of aspects.
{
AI12-0211-1}
Correction: Added a rule so that the a nonoverridable aspect has
to be the same for every ancestor of a type.
{
AI12-0064-2}
Removed formal parameters from the list of entities that don't have any
language-defined aspects, since Nonblocking (see
9.5)
is language-defined.
{
AI12-0373-1}
Added the missing definition for resolution of entities found in aspects
of library units.
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe