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/2
- {AI95-00385-01}
The deferred and full constants shall have the same type,
or shall have statically matching anonymous access subtypes;
5.a/2
Ramification: {
AI95-00385-01}
This implies that both the deferred declaration and the full declaration
have to have a
subtype_indication or access_definition rather than an
array_type_definition, because each
array_type_definition
would define a new type.
6/2
- {AI95-00385-01}
If the deferred constant declaration includes a subtype
defined by the subtype_indication that
defines a in the deferred declaration is
constrained subtype, 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/2
- {AI95-00231-01}
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.
7.1/2
- {AI95-00231-01}
If the subtype of the deferred constant declaration
excludes null, the subtype of the full declaration shall also exclude
null.
7.a.1/2
Ramification: On
the other hand, the full constant can exclude null even if the deferred
constant does not. But that can only happen for a subtype_indication,
as anonymous access types are required to statically match (which includes
any null_exclusion).
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/2
{
AI95-00256-01}
The completion of a deferred constant declaration shall occur before
the constant is frozen (see
13.14 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
13 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.114
CPU_Identifier :
constant String(1..8);
pragma Import(Assembler, CPU_Identifier, Link_Name => "CPU_ID");
--
see B.1Extensions 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.
Extensions to Ada 95
14.j/2
{
AI95-00385-01}
{extensions to Ada 95} Deferred
constants were enhanced to allow the use of anonymous access types in
them. Wording Changes from Ada 95
14.k/2
{
AI95-00231-01}
Added matching rules for subtypes that exclude
null.
Sponsored by Ada-Europe