4.9.1 Statically Matching Constraints and Subtypes
Static Semantics
{
AI95-00311-01}
A constraint
statically matches another constraint
if:
both are null constraints;
Discussion: A null
constraint has nothing to do with null exclusions! Unconstrained array
subtypes, subtypes with unknown discriminants, and subtypes with no explicit
constraint have null constraints (see 3.2).
This terminology became confusing when null exclusions were introduced
in the 2007 Amendment.
both are static and have equal corresponding bounds
or discriminant values;
{
AI95-00231-01}
{
AI95-00254-01}
{
AI05-0153-3}
{
AI12-0059-1}
{
AI12-0374-2}
A subtype
statically matches another subtype
of the same type if they have statically matching constraints, all predicate
specifications that apply to them come from the same declarations,
Nonblocking
aspects have the same value, global aspects statically match, Object_Size
(see 13.3) has been specified to have a nonconfirming
value for either both or neither, and the nonconfirming values, if any,
are the same, and, for access subtypes, either both or neither
exclude null. Two anonymous access-to-object subtypes statically match
if their designated subtypes statically match, and either both or neither
exclude null, and either both or neither are access-to-constant. Two
anonymous access-to-subprogram subtypes statically match if their designated
profiles are subtype conformant, and either both or neither exclude null.
Ramification: Statically matching constraints
and subtypes are the basis for subtype conformance of profiles (see
6.3.1).
Reason: Even though anonymous access
types always represent different types, they can statically match. That's
important so that they can be used widely. For instance, if this wasn't
true, access parameters and access discriminants could never conform,
so they couldn't be used in separate specifications.
Ramification: {
AI12-0059-1}
If one of the subtypes is not yet frozen, an implementation
may have to repeat the check when the subtypes are both frozen (as it
is impossible to check the Object_Size part before the subtypes are frozen).
This recheck can only make a previously statically matching subtype fail
to match; it cannot make a match legal.
Discussion: {
AI12-0059-1}
We exclude the case where both Object_Sizes are
confirming so that we don't introduce an incompatibility for existing
Ada code. But practically the implementation can simply check that the
Object_Size values are the same, as we have a rule in 13.1
that the subtype-specific aspects (such as Object_Size) are always the
same for statically matching subtypes. We wrote the rules this way to
avoid having wording that appeared to require predicting the future ("would
statically match if ...").
Two ranges of the same type
statically
match if both result from the same evaluation of a
range,
or if both are static and have equal corresponding bounds.
Ramification: The notion of static matching
of ranges is used in
12.5.3, “
Formal
Array Types”; the index ranges of formal and actual constrained
array subtypes have to statically match.
{
AI05-0086-1}
{
AI05-0153-3}
A constraint is
statically compatible with
a scalar subtype if it statically matches the constraint of the subtype,
or if both are static and the constraint is compatible with the subtype.
A constraint is
statically compatible with
an access or composite subtype if it statically matches the constraint
of the subtype, or if the subtype is unconstrained.
Discussion: Static compatibility is required
when constraining a parent subtype with a discriminant from a new
discriminant_part.
See
3.7. Static compatibility is also used
in matching generic formal derived types.
Note that statically compatible with a subtype
does not imply compatible with a type. It is OK since the terms are used
in different contexts.
{
AI05-0153-3}
Two statically matching subtypes are statically compatible
with each other. In addition, a subtype
S1 is statically compatible
with a subtype
S2 if:
the constraint of S1 is statically compatible
with S2, and
either:
all predicate specifications that
apply to S2 apply also to S1, or
{
AI05-0290-1}
{
AI12-0071-1}
both subtypes are static, every value that satisfies the
predicates predicate
of
S1 also satisfies the
predicates predicate
of
S2, and it is not the case that both types each have at least
one applicable predicate specification, predicate checks are enabled
(see
11.4.2) for
S2, and predicate
checks are not enabled for
S1.
Wording Changes from Ada 83
This subclause is new to Ada 95.
Wording Changes from Ada 95
{
AI95-00231-01}
{
AI95-00254-01}
Added static matching rules for null exclusions and anonymous access-to-subprogram
types; both of these are new.
{
AI95-00311-01}
We clarify that the constraint of the first subtype of a scalar formal
type statically matches itself.
Incompatibilities With Ada 2005
{
AI05-0086-1}
Correction: Updated the statically compatible
rules to take null exclusions into account. This is technically incompatible,
as it could cause a legal Ada 2005 program to be rejected; however, such
a program violates the intent of the rules (for instance,
3.7(15))
and this probably will simply detect bugs.
Wording Changes from Ada 2005
Wording Changes from Ada 2012
{
AI12-0071-1}
Corrigendum: Updated wording of static compatibility
to use the new term "satisfies the predicates" (see 3.2.4).{
AI12-0059-1}
Updated wording to take nonconfirming values of
Object_Size into account.{
AI12-0374-2}
Static matching now includes the effects of Global
aspects and the Nonblocking aspect.
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe
