7.4 Deferred Constants

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

{AI05-0229-1} {AI05-0269-1} The first part of the last sentence is redundant, as no imported entity may have a completion, as stated in B.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: {AI05-0004-1} For nonimported constants, these elaborations cannot require any code or checks for a legal program, because the given subtype_indication has to be indefinite or statically match that of the full constant, meaning that either it is a subtype_mark or it has static constraints. If the deferred constant instead has an access_definition, the designated subtype must be a subtype_mark. We still say that these are elaborated, however, because part of elaboration is creating the type, which is clearly needed for access_definitions. (A deferred constant and its full constant have different types when they are specified by an access_definition, although there is no visible effect of these types being different as neither can be named.) 

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. 

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. 

{AI05-0299-1} Since deferred constants can now be of a nonprivate type, we have made this a stand-alone subclause, 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} 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. 

{AI05-0062-1} Correction: Corrected rules so that the intent that a full constant may have a null exclusion even if the deferred constant does not is actually met.