13.1.1 Aspect Specifications

{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.)

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.

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. 

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. 

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). 

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.

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. 

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. 

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. 

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, inluding the syntax for specifying such aspects and the legality rules for such aspects.

{AI05-0183-1} {AI05-0229-1} {AI05-0267-1} Aspect specifications are new. 

{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 require 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.

{AI125-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.

{AI125-0106-1} Corrigendum: Defined class-wide aspect for use in rules in 13.13.2.

{AI125-0138-1} Corrigendum: Added a definition of nonoverridable aspects. This is necessary to prevent generic contract problems with formal derived types.