Ada Conformity Assessment Authority      Home Conformity Assessment   Test Suite ARGAda Standard
Annotated Ada Reference ManualLegal Information
Contents   Index   References   Search   Previous   Next 

3.11.1 Completions of Declarations

{8652/0014} {AI95-00064-01} {AI05-0177-1} Declarations sometimes come in two parts. A declaration that requires a second part is said to require completion. The second part is called the completion of the declaration (and of the entity declared), and is either another declaration, a body, or a pragma. A body is a body, an entry_body, a null_procedure_declaration or an expression_function_declaration that completes another declaration, or a renaming-as-body (see 8.5.4).
Discussion: Throughout the RM95, there are rules about completions that define the following: 
Which declarations require a corresponding completion.
Which constructs can only serve as the completion of a declaration.
Where the completion of a declaration is allowed to be.
What kinds of completions are allowed to correspond to each kind of declaration that allows one. 
Don't confuse this compile-time concept with the run-time concept of completion defined in 7.6.1.
Note that the declaration of a private type (if limited) can be completed with the declaration of a task type, which is then completed with a body. Thus, a declaration can actually come in three parts.
{AI95-00217-06} {AI05-0162-1} An incomplete type (whether declared in the limited view of a package or not) may be completed by a private type declaration, so we can in fact have four parts.
{AI05-0229-1} In Ada 2012, there are no language-defined pragmas that act as completions. Pragma Import (which is obsolescent) has the effect of setting aspect Import to True; such an aspect makes giving a completion illegal. The wording that allows pragmas as completions was left as it is harmless and appears in many places in this Standard. 

Name Resolution Rules

A construct that can be a completion is interpreted as the completion of a prior declaration only if: 
The declaration and the completion occur immediately within the same declarative region;
The defining name or defining_program_unit_name in the completion is the same as in the declaration, or in the case of a pragma, the pragma applies to the declaration;
If the declaration is overloadable, then the completion either has a type-conformant profile, or is a pragma.

Legality Rules

{AI05-0229-1} An implicit declaration shall not have a completion. For any explicit declaration that is specified to require completion, there shall be a corresponding explicit completion, unless the declared entity is imported (see B.1). 
To be honest: {AI95-00217-06} The implicit declarations occurring in a limited view do have a completion (the explicit declaration occurring in the full view) but that's a special case, since the implicit declarations are actually built from the explicit ones. So they do not require a completion, they have one by fiat.
Discussion: {AI05-0299-1} The implicit declarations of predefined operators are not allowed to have a completion. Enumeration literals, although they are subprograms, are not allowed to have a corresponding subprogram_body. That's because the completion rules are described in terms of constructs (subprogram_declarations) and not entities (subprograms). When a completion is required, it has to be explicit; the implicit null package_body that Clause 7 talks about cannot serve as the completion of a package_declaration if a completion is required. 
At most one completion is allowed for a given declaration. Additional requirements on completions appear where each kind of completion is defined. 
Ramification: A subunit is not a completion; the stub is.
If the completion of a declaration is also a declaration, then that declaration might have a completion, too. For example, a limited private type can be completed with a task type, which can then be completed with a task body. This is not a violation of the “at most one completion” rule. 
A type is completely defined at a place that is after its full type definition (if it has one) and after all of its subcomponent types are completely defined. A type shall be completely defined before it is frozen (see 13.14 and 7.3). 
Reason: Index types are always completely defined — no need to mention them. There is no way for a completely defined type to depend on the value of a (still) deferred constant. 
98  {AI05-0229-1} Completions are in principle allowed for any kind of explicit declaration. However, for some kinds of declaration, the only allowed completion is an implementation-defined pragma, and implementations are not required to have any such pragmas. 
This paragraph was deleted.{AI05-0229-1}
99  There are rules that prevent premature uses of declarations that have a corresponding completion. The Elaboration_Checks of 3.11 prevent such uses at run time for subprograms, protected operations, tasks, and generic units. The rules of 13.14, “Freezing Rules” prevent, at compile time, premature uses of other entities such as private types and deferred constants. 

Wording Changes from Ada 83

This subclause is new. It is intended to cover all kinds of completions of declarations, be they a body for a spec, a full type for an incomplete or private type, a full constant declaration for a deferred constant declaration, or a pragma Import for any kind of entity. 

Wording Changes from Ada 95

{8652/0014} {AI95-00064-01} Corrigendum: Added a definition of body, which is different than body or body

Wording Changes from Ada 2005

{AI95-0177-1} Added null procedures and expression functions that are completions to the definition of body

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