!standard 7.4(6/3) 22-06-14 AI22-0041-1/01
!class binding interpretation 22-06-14
!status work item 22-06-14
!status received 22-06-07
!subject Deferred constant subtype compatibility
A dDeferred constant should not be completed with an incompatible subtype.
The subtype given in the declaration of a deferred constant is part of the “contract” of the declaration. Clients should be able to assume that if the completion elaborates successfully, then the value of the constant satisfies any checks (such as constraints, null exclusions, and enabled predicates) associated with that initial subtype. It is currently permitted to have a deferred constant whose initial subtype is subject to some (enabled) predicate which the completion’s subtype is not subject to and which will therefore not be checked when the completion is elaborated. This seems undesirable.
Should this example be legal? (No.)
package Bad_Deferred_Constant is
Require (at compile time) that the subtype used in the completion of a deferred constant shall be “statically compatible” with the subtype used in the initial declaration.
Delete 7.4(6/3) :
If the deferred constant declaration includes a subtype_indication S that defines a constrained subtype, then the constraint defined by the subtype_indication in the full declaration shall match the constraint defined by S statically. [Redundant: 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;]
Add after 7.4(6/3):
If the deferred constant declaration includes a subtype_indication that defines a subtype S1, then the subtype_indication in the full declaration shall define a subtype S2 that is statically compatible with S1 (see 4.9.1). If S1 is a constrained subtype, the constraint defined by S2 shall statically match the constraint defined by S1. [Redundant: If the subtype S1 of the deferred constant is unconstrained, then the full declaration is still allowed to impose a constraint.]
One could imagine dealing with this issue by somehow checking the value given in the completion of a deferred constant against both of the two subtypes. Adding complexity to the dynamic semantics of deferred constants does not seem like the right approach; better to deal with the issue statically.
See !Issue section.
A B-test similar to the given example could be written.