7.4 Deferred Constants

Proof: The first sentence is redundant, as it is stated officially in 3.3.1. 

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. 

Ramification: On the other hand, the full constant can be aliased even if the deferred constant is not. 

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).

Ramification: Multiple or single declarations are allowed for the deferred and the full declarations, provided that the equivalent single declarations would be allowed.

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. 

{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.

In Ada 83, a deferred constant declaration was not permitted to include a constraint, nor the reserved word aliased.

In Ada 83, the rules required conformance of type marks; here we require static matching of subtypes if the deferred constant is constrained.

A deferred constant declaration can be completed with a pragma Import. Such a deferred constant declaration need not be within a package_specification.

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.

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.

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. 

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”.

Deferred constant declarations used to have their own syntax, but now they are simply a special case of object_declarations.

{AI95-00385-01} {extensions to Ada 95} Deferred constants were enhanced to allow the use of anonymous access types in them. 

{AI95-00231-01} Added matching rules for subtypes that exclude null.