Contents   Index   Previous   Next

7.4 Deferred Constants

1
   [Deferred constant declarations may be used to declare constants in the visible part of a package, but with the value of the constant given in the private part. They may also be used to declare constants imported from other languages (see Annex B).]

Legality Rules

2
   [{deferred constant declaration} A deferred constant declaration is an object_declaration with the reserved word constant but no initialization expression.] {deferred constant} The constant declared by a deferred constant declaration is called a deferred constant. {requires a completion (deferred constant declaration) [partial]} A deferred constant declaration requires a completion, which shall be a full constant declaration (called the full declaration of the deferred constant), or a pragma Import (see Annex B). {full declaration}
2.a
Proof: The first sentence is redundant, as it is stated officially in 3.3.1.
3
   A deferred constant declaration that is completed by a full constant declaration shall occur immediately within the visible part of a package_specification. For this case, the following additional rules apply to the corresponding full declaration:
4
5
5.a
Ramification: This implies that both the deferred declaration and the full declaration have to have a subtype_indication rather than an array_type_definition, because each array_type_definition would define a new type.
6
7
7.a
Ramification: On the other hand, the full constant can be aliased even if the deferred constant is not.
8
   [A deferred constant declaration that is completed by a pragma Import need not appear in the visible part of a package_specification, and has no full constant declaration.]
9
   The completion of a deferred constant declaration shall occur before the constant is frozen (see 7.4).

Dynamic Semantics

10
    {elaboration (deferred constant declaration) [partial]} The elaboration of a deferred constant declaration elaborates the subtype_indication or (only allowed in the case of an imported constant) the array_type_definition.
NOTES
11
12  The full constant declaration for a deferred constant that is of a given private type or private extension is not allowed before the corresponding full_type_declaration. This is a consequence of the freezing rules for types (see 13.14).
11.a
Ramification: Multiple or single declarations are allowed for the deferred and the full declarations, provided that the equivalent single declarations would be allowed.
11.b
Deferred constant declarations are useful for declaring constants of private views, and types with components of private views. They are also useful for declaring access-to-constant objects that designate variables declared in the private part of a package.

Examples

12
    Examples of deferred constant declarations:
13
Null_Key : constant Key;      -- see 7.3.1
14
CPU_Identifier : constant String(1..8);
pragma Import(Assembler, CPU_Identifier, Link_Name => "CPU_ID");
                              -- see B.1

Extensions to Ada 83

14.a
{extensions to Ada 83} In Ada 83, a deferred constant is required to be of a private type declared in the same visible part. This restriction is removed for Ada 95; deferred constants can be of any type.
14.b
In Ada 83, a deferred constant declaration was not permitted to include a constraint, nor the reserved word aliased.
14.c
In Ada 83, the rules required conformance of type marks; here we require static matching of subtypes if the deferred constant is constrained.
14.d
A deferred constant declaration can be completed with a pragma Import. Such a deferred constant declaration need not be within a package_specification.
14.e
The rules for too-early uses of deferred constants are modified in Ada 95 to allow more cases, and catch all errors at compile time. This change is necessary in order to allow deferred constants of a tagged type without violating the principle that for a dispatching call, there is always an implementation to dispatch to. It has the beneficial side-effect of catching some Ada-83-erroneous programs at compile time. The new rule fits in well with the new freezing-point rules. Furthermore, we are trying to convert undefined-value problems into bounded errors, and we were having trouble for the case of deferred constants. Furthermore, uninitialized deferred constants cause trouble for the shared variable / tasking rules, since they are really variable, even though they purport to be constant. In Ada 95, they cannot be touched until they become constant.
14.f
Note that we do not consider this change to be an upward incompatibility, because it merely changes an erroneous execution in Ada 83 into a compile-time error.
14.g
The Ada 83 semantics are unclear in the case where the full view turns out to be an access type. It is a goal of the language design to prevent uninitialized access objects. One wonders if the implementation is required to initialize the deferred constant to null, and then initialize it (again!) to its real value. In Ada 95, the problem goes away.

Wording Changes from Ada 83

14.h
Since deferred constants can now be of a nonprivate type, we have made this a stand-alone clause, rather than a subclause of 7.3, ``Private Types and Private Extensions''.
14.i
Deferred constant declarations used to have their own syntax, but now they are simply a special case of object_declarations.

Contents   Index   Previous   Next   Legal