Contents Index Search 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
- The full declaration shall occur immediately
within the private part of the same package;
5
- The deferred and full constants shall
have the same type;
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
- If the subtype defined by the subtype_indication
in the deferred declaration is constrained, then the subtype defined
by the subtype_indication in the
full declaration shall match it statically. [On the other hand, if the
subtype of the deferred constant is unconstrained, then the full declaration
is still allowed to impose a constraint. The constant itself will be
constrained, like all constants;]
7
- If the deferred constant declaration
includes the reserved word aliased, then the full declaration
shall also.
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.
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
14.i
Deferred constant declarations
used to have their own syntax, but now they are simply a special case
of object_declarations.
Contents Index Search Previous Next Legal