- (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.
Name Resolution Rules
- (2)
- A construct that can be a completion is interpreted as the completion of
a prior declaration only if:
- (3)
- The declaration and the completion occur immediately within the
same declarative region;
- (4)
- 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;
- (5)
- If the declaration is overloadable, then the completion either
has a type-conformant profile, or is a pragma.
Legality Rules
- (6)
- 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.
- (7)
- At most one completion is allowed for a given declaration. Additional
requirements on completions appear where each kind of completion is defined.
- (8)
- 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).
-
- (9)
(88) Completions are in principle allowed for any kind of explicit
declaration. However, for some kinds of declaration, the only allowed
completion is a pragma Import, and implementations are not required to
support pragma Import for every kind of entity.
- (10)
(89) 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.
-- Email comments, additions, corrections, gripes, kudos, etc. to:
Magnus Kempe -- Magnus.Kempe@di.epfl.ch
Copyright statement
Page last generated: 95-03-12