Ada Resource Association
News and resources for the Ada programming language
Annotated Ada Reference ManualLegal Information
Contents   Index   References   Search   Previous   Next 

13.1.1 Aspect Specifications

1/3
{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

2/3
{AI05-0183-1} aspect_specification ::= 
   with aspect_mark [=> aspect_definition] {,
           aspect_mark [=> aspect_definition] }
3/3
{AI05-0183-1} aspect_mark ::= aspect_identifier['Class]
4/3
{AI05-0183-1} aspect_definition ::= name | expression | identifier

Language Design Principles

4.a/3
{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).
4.b/3
basic_declaration
  type_declaration
    full_type_declaration
      type declaration syntax*
      task_type_declaration*
      protected_type_declaration*
    incomplete_type_declaration  --  NO
      -- Incomplete type aspects cannot be read by an attribute or specified by attribute_definition_clause
      -- (the attribute name is illegal), so it would not make sense to allow this in another way.
    private_type_declaration*
    private_extension_declaration*
  subtype_declaration*
  object_declaration
    object declaration syntax*
    single_task_declaration*
    single_protected_declaration*
  number_declaration  --  NO
  subprogram_declaration*
  abstract_subprogram_declaration*
  null_procedure_declaration*
  package_declaration*  -- via package_specification
  renaming_declaration*
    -- There are no language-defined aspects that may be specified
    -- on renames, but implementations might support some.
  exception_declaration*
  generic_declaration
    generic_subprogram_declaration*
    generic_package_declaration* -- via package_specification
  generic_instantiation*
enumeration_literal_specification  --  NO
discriminant_specification  --  NO
component_declaration*
loop_parameter_specification  --  NO
iterator_specification  --  NO
parameter_specification  --  NO
subprogram_body*  --   - but language-defined aspects only if there is no explicit specification
entry_declaration*
entry_index_specification  --  NO
subprogram_body_stub*  --   - but language-defined aspects only if there is no explicit specification
choice_parameter_specification  --  NO
generic_formal_parameter_declaration
    -- There are no language-defined aspects that may be specified
    -- on generic formals, but implementations might support some.
  formal_object_declaration*
  formal_type_declaration*
  formal_subprogram_declaration
    formal_concrete_subprogram_declaration*
    formal_abstract_subprogram_declaration*
  formal_package_declaration*
extended_return_statement  --  NO
4.c/3
-- We also allow aspect_specifications on all kinds of bodies, but are no language-defined aspects
-- that may be specified on a body. These are allowed for implementation-defined aspects.
-- See above for subprogram bodies and stubs (as these can be declarations).
package_body*
task_body*
protected_body*
package_body_stub*
task_body_stub*
protected_body_stub*
4.d/3
{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

5/3
{AI05-0183-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, a subprogram, or some other kind of entity. If the aspect_mark identifies: 
6/3
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;
7/3
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;
8/3
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;
9/3
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;
10/3
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.
11/3
 {AI05-0183-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.
12/3
 {AI05-0183-1} 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

13/3
 {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.
14/3
 {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).
15/3
 {AI05-0183-1} The aspect_definition associated with a given aspect_mark may be omitted only when the aspect_mark identifies an aspect of a boolean type, in which case it is equivalent to the aspect_definition being specified as True.
16/3
 {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.
17/3
 {AI05-0183-1} {AI05-0267-1} There are no language-defined aspects that may be specified on a renaming_declaration, a generic_formal_parameter_declaration, a subunit, a package_body, a task_body, a protected_body, or a body_stub other than a subprogram_body_stub.
17.a/3
Discussion: Implementation-defined aspects can be allowed on these, of course; the implementation will need to define the semantics. In particular, the implementation will need to define actual type matching rules for any aspects allowed on formal types; there are no default matching rules defined by the language.
18/3
 {AI05-0183-1} {AI05-0267-1} A language-defined aspect shall not be specified in an aspect_specification given on a subprogram_body or subprogram_body_stub that is a completion of another declaration.
18.a/3
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. 

Static Semantics

19/3
 {AI05-0183-1} Depending on which aspect is identified by the aspect_mark, an aspect_definition specifies: 
20/3
a name that denotes a subprogram, object, or other kind of entity;
21/3
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
22/3
an identifier specific to the aspect. 
23/3
 {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:
24/3
An aspect specified on an object_declaration;
25/3
An aspect specified on a subprogram_declaration;
26/3
An aspect specified on a renaming_declaration.
27/3
 {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.
28/3
 {AI05-0183-1} If the aspect_mark includes 'Class, then: 
29/3
if the associated entity is a tagged type, the specification applies to all descendants of the type;
30/3
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. 
31/3
 {AI05-0183-1} {AI05-0229-1} All specifiable operational and representation attributes may be specified with an aspect_specification instead of an attribute_definition_clause (see 13.3).
31.a/3
Ramification: The name of the aspect is the same as that of the attribute (see 13.3), so the aspect_mark is the attribute_designator of the attribute. 
32/3
 {AI05-0229-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.
32.a/3
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. 
33/3
 {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.
34/3
 {AI05-0183-1} 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.
35/3
 {AI05-0183-1} 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.
35.a/3
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. 
36/3
 {AI05-0183-1} Alternative legality and semantics rules may apply for particular aspects, as specified elsewhere in this International Standard.

Dynamic Semantics

37/3
 {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

38/3
 {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.
38.a/3
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. 
38.a.1/3
Implementation defined: Implementation-defined aspects, inluding the syntax for specifying such aspects and the legality rules for such aspects.

Extensions to Ada 2005

38.b/3
{AI05-0183-1} {AI05-0229-1} {AI05-0267-1} Aspect specifications are new.

Contents   Index   References   Search   Previous   Next 
Ada-Europe Ada 2005 and 2012 Editions sponsored in part by Ada-Europe