13.1.1 Aspect Specifications
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
Name Resolution Rules
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, 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;
 
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. 
 
 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.
 
 If the associated declaration is for a subprogram 
or entry, 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 components 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
 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.
 
 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).
 
 If the 
aspect_mark 
includes 'Class, then the associated entity shall be a tagged type or 
a primitive subprogram of a tagged type.
 
 A language-defined aspect shall not be specified 
in an 
aspect_specification 
given on a completion of a subprogram or generic subprogram.
 
   If an aspect of a derived type is inherited from 
an ancestor type and has the boolean value True, the inherited value 
shall not be overridden to have the value False for the derived type, 
unless otherwise specified in this International Standard.
   Certain type-related aspects are defined to be 
nonoverridable; all such aspects are specified using an 
aspect_definition 
that is a 
name.
 
   If a nonoverridable aspect is directly specified 
for a type 
T, then any explicit specification of that aspect for 
any other descendant of 
T shall be 
confirming;
 
that is, the specified 
name 
shall 
match the inherited aspect, meaning 
that the specified 
name 
shall denote the same declarations as would the inherited 
name.
 
   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.
   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.
 
   The Default_Iterator, Iterator_Element, Implicit_Dereference, 
Constant_Indexing, and Variable_Indexing aspects are nonoverridable.
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
 
 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:
 
 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 
aspect_mark 
includes 'Class (a 
class-wide aspect)
, 
then, unless specified otherwise for a particular class-wide aspect: 
 
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.
 
 
 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.
 
 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.
 This paragraph was 
deleted.
 If a Legality Rule or Static Semantics rule only 
applies when a particular aspect has been specified, the aspect is considered 
to have been specified only when the 
aspect_specification 
or 
attribute_definition_clause 
is visible (see 
8.3) at the point of the application 
of the rule.
 
 Alternative legality and semantics rules may apply 
for particular aspects, as specified elsewhere in this International 
Standard.
Dynamic Semantics
 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
 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. 
 
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe