Skip to main content

4.9 Static Expressions and Static Subtypes

danger

This Reference Manual output has not been verified, and may contain omissions or errors. Report any problems on the tracking issue

1

Certain expressions of a scalar or string type are defined to be static. Similarly, certain discrete ranges are defined to be static, and certain scalar and string subtypes are defined to be static subtypes. [ Static means determinable at compile time, using the declared properties or values of the program entities.]

1.a
discussion
As opposed to more elaborate data flow analysis, etc.

Language Design Principles​

1.b
note
For an expression to be static, it has to be calculable at compile time.
1.c
note
Only scalar and string expressions are static.
1.d
note
To be static, an expression cannot have any nonscalar, nonstring subexpressions (though it can have nonscalar constituent names). A static scalar expression cannot have any nonscalar subexpressions. There is one exception — a membership test for a string subtype can be static, and the result is scalar, even though a subexpression is nonscalar.
1.e
note
The rules for evaluating static expressions are designed to maximize portability of static calculations.
1.f/5
reason
We support static string expressions so that, for example, the aspect_definition for a Link_Name aspect can contain a concatenation. We don't support static aggregates (even for string types) or non-string static nonscalar types; we're trying to keep it cheap and simple (from the implementer's viewpoint).

Static Semantics​

2

A static expression is [a scalar or string expression that is] one of the following:

3/5
3.a/5
ramification
A numeric_literal of a numeric type is always a static expression, even if its expected type is not that of a static subtype. However, if its value is explicitly converted to, or qualified by, a nonstatic subtype, the resulting expression is nonstatic. Non-numeric types can have numeric literals if aspect Integer_Literal or Real_Literal is used; these are never static.
4
4.a
ramification
That is, the constrained subtype defined by the index range of the string is static. Note that elementary values don't generally have subtypes, while composite values do (since the bounds or discriminants are inherent in the value).
5/5
  • a name that denotes the declaration of a static constant;
    • 5.1/5
  • a name that denotes a named number, and that is interpreted as a value of a numeric type;
5.a.1/5
note
To be honest: This is referring the resolution of the named number and not the Static Semantics (for which all named numbers are values of a universal numeric type). The word “interpreted” is intended to make the distinction.
5.a
ramification
Note that enumeration literals are covered by the function_call case.
6
  • a function_call whose function_name or function_prefix statically denotes a static function, and whose actual parameters, if any (whether given explicitly or by default), are all static expressions;
6.a
ramification
This includes uses of operators that are equivalent to function_calls.
7
7.a
ramification
Note that this does not include the case of an attribute that is a function; a reference to such an attribute is not even an expression. See above for function calls.
7.b
note
An implementation may define the staticness and other properties of implementation-defined attributes.
8/5
10.a
ramification
This rules out the subtype_mark'aggregate case.
10.b
reason
Adding qualification to an expression shouldn't make it nonstatic, even for strings.
11/4
11.a
reason
Clearly, we should allow membership tests in exactly the same cases where we allow qualified_expressions.
12
13.a
discussion
Informally, we talk about a static value. When we do, we mean a value specified by a static expression.
13.b/5
ramification
The language requires a static expression in a number_declaration, a numeric type definition, certain representation items, and a number of other contexts .
14

A name statically denotes an entity if it denotes the entity and:

15
17.a
ramification
Selected_components that are not expanded names and indexed_components do not statically denote things.
17.1/5

A name statically names an object if it:

17.2/5
  • statically denotes the declaration of an object [(possibly through one or more renames)];
17.b/5
proof
Follows from the definition of statically denotes.
17.3/5
17.c/5
reason
We disallow components in a variant_part so that no discriminant checks are needed to evaluate the selected_component. Note that other kinds of discriminant-dependent components do not need any checks on access (only when they are changed).
17.4/5
  • is an indexed_component whose prefix statically names an object, there is no implicit dereference of the prefix, the object is statically constrained, and the index expressions of the object are static and have values that are within the range of the index constraint.
17.5/5

For an entity other than an object, a name statically names an entity if the name statically denotes the entity.

18

A static function is one of the following:

18.a
ramification
These are the functions whose calls can be static expressions.
19
  • a predefined operator whose parameter and result types are all scalar types none of which are descendants of formal scalar types;
    • 19.1/5
  • a predefined relational operator whose parameters are of a string type that is not a descendant of a formal array type;
    • 20/5
  • a predefined concatenation operator whose result type is a string type that is not a descendant of a formal array type;
    • 20.1/5
  • a shifting or rotating function associated with a modular type declared in package Interfaces (see B.2);
    • 21
  • an enumeration literal;
    • 21.1/5
  • a static expression function (see 6.8);
    • 22
  • a language-defined attribute that is a function, if the prefix denotes a static scalar subtype, and if the parameter and result types are scalar.
23

In any case, a generic formal subprogram is not a static function.

24/5

A static constant is a constant view declared by a full constant declaration or an object_renaming_declaration with a static nominal subtype, having a value defined by a static scalar expression or by a static string expression, and which satisfies any constraint or predicate that applies to the nominal subtype .

24.a
ramification
A deferred constant is not static; the view introduced by the corresponding full constant declaration can be static.
24.b/5
reason
This paragraph was deleted.
24.c/5
note
This paragraph was deleted.
25

A static range is a range whose bounds are static expressions, [or a range_attribute_reference that is equivalent to such a range.] A static discrete_range is one that is a static range or is a subtype_indication that defines a static scalar subtype. The base range of a scalar type is a static range, unless the type is a descendant of a formal scalar type.

26/3

A static subtype is either a static scalar subtype or a static string subtype. A static scalar subtype is an unconstrained scalar subtype whose type is not a descendant of a formal type, or a constrained scalar subtype formed by imposing a compatible static constraint on a static scalar subtype. A static string subtype is an unconstrained string subtype whose index subtype and component subtype are static, or a constrained string subtype formed by imposing a compatible static constraint on a static string subtype. In any case, the subtype of a generic formal object of mode in out, and the result subtype of a generic formal function, are not static. Also, a subtype is not static if any Dynamic_Predicate specifications apply to it.

26.a
ramification
String subtypes are the only composite subtypes that can be static.
26.b
reason
The part about generic formal objects of mode in out is necessary because the subtype of the formal is not required to have anything to do with the subtype of the actual. For example:
26.c
subtype Int10 is Integer range 1..10;
26.dgeneric
    F : in out Int10;
procedure G;
26.eprocedure G is
begin
    case F is
        when 1..10 => null;
        -- Illegal!
    end case;
end G;
26.fX : Integer range 1..20;
procedure I is new G(F => X); -- OK.
26.g
note
The case_statement is illegal, because the subtype of F is not static, so the choices have to cover all values of Integer, not just those in the range 1..10. A similar issue arises for generic formal functions, now that function calls are object names.
27

The different kinds of static constraint are defined as follows:

28
  • A null constraint is always static;
    • 29
  • A scalar constraint is static if it has no range_constraint, or one with a static range;
    • 30
  • An index constraint is static if each discrete_range is static, and each index subtype of the corresponding array type is static;
    • 31
  • A discriminant constraint is static if each expression of the constraint is static, and the subtype of each discriminant is static.
31.1/2

In any case, the constraint of the first subtype of a scalar formal type is neither static nor null.

32

A subtype is statically constrained if it is constrained, and its constraint is static. An object is statically constrained if its nominal subtype is statically constrained, or if it is a static string constant.

Legality Rules​

32.1/3

An expression is statically unevaluated if it is part of:

32.2/3
32.a/3
reason
We need this bullet so that only a single dependent_expression is evaluated in a static if_expression if there is more than one condition that evaluates to True. The part about conditions makes
32.b/3
(if N = 0 then Min elsif 10_000/N > Min then 10_000/N else Min)
32.c/3
note
legal if N and Min are static and N = 0.
32.d/3
discussion
We need the "of the if_expression" here so there is no confusion for nested if_expressions; this rule only applies to the conditions and dependent_expressions of a single if_expression. Similar reasoning applies to the "of a case_expression" of the last bullet.
32.5/3
33/3

A static expression is evaluated at compile time except when it is statically unevaluated. The compile-time evaluation of a static expression is performed exactly, without performing Overflow_Checks. For a static expression that is evaluated:

34/3
  • The expression is illegal if its evaluation fails a language-defined check other than Overflow_Check. For the purposes of this evaluation, the assertion policy is assumed to be Check.
34.a/3
reason
Assertion policies can control whether checks are made, but we don't want assertion policies to affect legality. For Ada 2012, subtype predicates are the only checks controlled by the assertion policy that can appear in static expressions.
35/2
  • If the expression is not part of a larger static expression and the expression is expected to be of a single specific type, then its value shall be within the base range of its expected type. Otherwise, the value may be arbitrarily large or small.
35.a/2
ramification
If the expression is expected to be of a universal type, or of “any integer type”, there are no limits on the value of the expression.
36/2
  • If the expression is of type universal_real and its expected type is a decimal fixed point type, then its value shall be a multiple of the small of the decimal type. This restriction does not apply if the expected type is a descendant of a formal scalar type (or a corresponding actual type in an instance).
36.a
ramification
This means that a numeric_literal for a decimal type cannot have “extra” significant digits.
36.b/2
reason
The small is not known for a generic formal type, so we have to exclude formal types from this check.
37/2

In addition to the places where Legality Rules normally apply (see 12.3), the above restrictions also apply in the private part of an instance of a generic unit.

37.a
discussion
Values outside the base range are not permitted when crossing from the “static” domain to the “dynamic” domain. This rule is designed to enhance portability of programs containing static expressions. Note that this rule applies to the exact value, not the value after any rounding or truncation. (See below for the rounding and truncation requirements.)
37.b
note
Short-circuit control forms are a special case:
37.c
N: constant := 0.0;
X: constant Boolean := (N = 0.0) or else (1.0/N > 0.5); -- Static.
37.d
note
The declaration of X is legal, since the divide-by-zero part of the expression is not evaluated. X is a static constant equal to True.
37.e/5
note
The preceding “statically unevaluated” rule allows
37.f/5
X : constant := (if True then 37 else (1 / 0));
37.g/5
note
but does not allow
37.h/5
function If_Then_Else (Flag : Boolean; X, Y : Integer) return Integer is
   (if Flag then X else Y) with Static; -- see 6.8
X : constant := If_Then_Else (True, 37, 1 / 0);
37.i/5
note
because evaluation of a function call includes evaluation of all of its actual parameters.

Implementation Requirements​

38/2

For a real static expression that is not part of a larger static expression, and whose expected type is not a descendant of a formal type, the implementation shall round or truncate the value (according to the Machine_Rounds attribute of the expected type) to the nearest machine number of the expected type; if the value is exactly half-way between two machine numbers, the rounding performed is implementation-defined. If the expected type is a descendant of a formal type, or if the static expression appears in the body of an instance of a generic unit and the corresponding expression is nonstatic in the corresponding generic body, then no special rounding or truncating is required — normal accuracy rules apply (see Annex G).

38.a.1/2
implementation defined
Rounding of real static expressions which are exactly half-way between two machine numbers.
38.a/2
reason
Discarding extended precision enhances portability by ensuring that the value of a static constant of a real type is always a machine number of the type.
38.b
note
When the expected type is a descendant of a formal floating point type, extended precision (beyond that of the machine numbers) can be retained when evaluating a static expression, to ease code sharing for generic instantiations. For similar reasons, normal (nondeterministic) rounding or truncating rules apply for descendants of a formal fixed point type.
38.b.1/2
note
There is no requirement for exact evaluation or special rounding in an instance body (unless the expression is static in the generic body). This eliminates a potential contract issue where the exact value of a static expression depends on the actual parameters (which could then affect the legality of other code).
38.c
implementation note
Note that the implementation of static expressions has to keep track of plus and minus zero for a type whose Signed_Zeros attribute is True.
38.d/2
note
Note that the only machine numbers of a fixed point type are the multiples of the small, so a static conversion to a fixed-point type, or division by an integer, must do truncation to a multiple of small. It is not correct for the implementation to do all static calculations in infinite precision.

Implementation Advice​

38.1/2

For a real static expression that is not part of a larger static expression, and whose expected type is not a descendant of a formal type, the rounding should be the same as the default rounding for the target system.

38.e/2
implementation advice
A real static expression with a nonformal type that is not part of a larger static expression should be rounded the same as the target system.
39
note
NOTE 1 An expression can be static even if it occurs in a context where staticness is not required.
39.a
ramification
For example:
39.b
X : Float := Float'(1.0E+400) + 1.0 - Float'(1.0E+400);
39.c
note
The expression is static, which means that the value of X must be exactly 1.0, independent of the accuracy or range of the run-time floating point implementation.
39.d
note
The following kinds of expressions are never static: explicit_dereference, indexed_component, slice, null, aggregate, allocator.
40
note
NOTE 2 A static (or run-time) type_conversion from a real type to an integer type performs rounding. If the operand value is exactly half-way between two integers, the rounding is performed away from zero.
40.a
reason
We specify this for portability. The reason for not choosing round-to-nearest-even, for example, is that this method is easier to undo.
40.b
ramification
The attribute Truncation (see A.5.3) can be used to perform a (static) truncation prior to conversion, to prevent rounding.
40.c
implementation note
The value of the literal 0E999999999999999999999999999999999999999999999 is zero. The implementation must take care to evaluate such literals properly.

Examples​

41

Examples of static expressions:

42
1 + 1       -- 2
abs(-10)*3  -- 30
43Kilo : constant := 1000;
Mega : constant := Kilo*Kilo;   -- 1_000_000
Long : constant := Float'Digits*2;
44Half_Pi    : constant := Pi/2;           -- see 3.3.2
Deg_To_Rad : constant := Half_Pi/90;
Rad_To_Deg : constant := 1.0/Deg_To_Rad; -- equivalent to 1.0/((3.14159_26536/2)/90)

Extensions to Ada 83​

44.a
note
The rules for static expressions and static subtypes are generalized to allow more kinds of compile-time-known expressions to be used where compile-time-known values are required, as follows:
44.b
  • Membership tests and short-circuit control forms may appear in a static expression.
    • 44.c
  • The bounds and length of statically constrained array objects or subtypes are static.
    • 44.d
  • The Range attribute of a statically constrained array subtype or object gives a static range.
    • 44.e
  • A type_conversion is static if the subtype_mark denotes a static scalar subtype and the operand is a static expression.
    • 44.f
  • All numeric literals are now static, even if the expected type is a formal scalar type. This is useful in case_statements and variant_parts, which both now allow a value of a formal scalar type to control the selection, to ease conversion of a package into a generic package. Similarly, named array aggregates are also permitted for array types with an index type that is a formal scalar type.
44.g
note
The rules for the evaluation of static expressions are revised to require exact evaluation at compile time, and force a machine number result when crossing from the static realm to the dynamic realm, to enhance portability and predictability. Exact evaluation is not required for descendants of a formal scalar type, to simplify generic code sharing and to avoid generic contract model problems.
44.h
note
Static expressions are legal even if an intermediate in the expression goes outside the base range of the type. Therefore, the following will succeed in Ada 95, whereas it might raise an exception in Ada 83:
44.i
type Short_Int is range -32_768 .. 32_767;
I : Short_Int := -32_768;
44.j
note
This might raise an exception in Ada 83 because "32_768" is out of range, even though "–32_768" is not. In Ada 95, this will always succeed.
44.k
note
Certain expressions involving string operations (in particular concatenation and membership tests) are considered static in Ada 95.
44.l
note
The reason for this change is to simplify the rule requiring compile-time-known string expressions as the link name in an interfacing pragma, and to simplify the preelaborability rules.

Incompatibilities With Ada 83​

44.m
note
An Ada 83 program that uses an out-of-range static value is illegal in Ada 95, unless the expression is part of a larger static expression, or the expression is not evaluated due to being on the right-hand side of a short-circuit control form.

Wording Changes from Ada 83​

44.n/3
note
This subclause (and 4.5.5, “Multiplying Operators”) subsumes the RM83 section on Universal Expressions.
44.o
note
The existence of static string expressions necessitated changing the definition of static subtype to include string subtypes. Most occurrences of "static subtype" have been changed to "static scalar subtype", in order to preserve the effect of the Ada 83 rules. This has the added benefit of clarifying the difference between "static subtype" and "statically constrained subtype", which has been a source of confusion. In cases where we allow static string subtypes, we explicitly use phrases like "static string subtype" or "static (scalar or string) subtype", in order to clarify the meaning for those who have gotten used to the Ada 83 terminology.
44.p
note
In Ada 83, an expression was considered nonstatic if it raised an exception. Thus, for example:
44.q
Bad: constant := 1/0; -- Illegal!
44.r
note
was illegal because 1/0 was not static. In Ada 95, the above example is still illegal, but for a different reason: 1/0 is static, but there's a separate rule forbidding the exception raising.

Inconsistencies With Ada 95​

44.s/2
correction
Amendment Rounding of static real expressions is implementation-defined in Ada 2005, while it was specified as away from zero in (original) Ada 95. This could make subtle differences in programs. However, the original Ada 95 rule required rounding that (probably) differed from the target processor, thus creating anomalies where the value of a static expression was required to be different than the same expression evaluated at run time.

Wording Changes from Ada 95​

44.t/2
note
The Ada 95 wording that defined static subtypes unintentionally failed to exclude formal derived types that happen to be scalar (these aren't formal scalar types); and had a parenthetical remark excluding formal string types - but that was neither necessary nor parenthetical (it didn't follow from other wording). This issue also applies to the rounding rules for real static expressions.
44.u/2
note
Ada 95 didn't clearly define the bounds of a value of a static expression for universal types and for “any integer/float/fixed type”. We also make it clear that we do not intend exact evaluation of static expressions in an instance body if the expressions aren't static in the generic body.
44.v/2
note
We clarify that the first subtype of a scalar formal type has a nonstatic, nonnull constraint.

Wording Changes from Ada 2005​

44.w/3
note
Added wording to define staticness and the lack of evaluation for if_expressions and case_expressions. These are new and defined elsewhere.
44.x/3
note
Added wording to prevent subtypes that have dynamic predicates (see 3.2.4) from being static.
44.y/3
note
Revised wording for membership tests to allow for the new possibilities allowed by the membership_choice_list.

Incompatibilities With Ada 2012​

44.z/5
note
Added a missing exclusion for concatenations of a string type descended from a formal array type. This could potentially make some expression non-static; but as that could only matter in a context where a static string is required (such as the Link_Name aspect), it is quite unlikely.
44.aa/5
note
Shifting and rotating functions declared in package Interfaces are now static. This could potentially make some expression illegal that is legal if nonstatic (as in Ada 2012). While this can happen especially in conditional code that is not in use, it is quite unlikely given typical uses of shifting or rotating functions.

Extensions to Ada 2012​

44.bb/5
note
Expressions involving string relational operators or string type conversions now can be static. Additionally, the length limit on static string constants was removed as being a hazard without much help to implementations.

Wording Changes from Ada 2012​

44.cc/5
note
Defined the staticness of the Nonblocking attribute (see 9.5).
44.dd/5
note
Expression functions can be static if declared correctly; this is documented as an extension in 6.8.
44.ee/5
note
A numeric_literal or named number can be non-static if they interpreted using an Integer_Literal or Real_Literal aspect (see 4.2.1).
44.ff/5
note
Clarified that a target name symbol can statically denote an entity if the associated variable_name statically denotes an entity. This is necessary so that target names participate in the anti-order-dependence checks of 6.4.1.
44.gg/3
note
Added wording to define staticness for declare_expressions. Also moved “statically names” definition here and used it in array attribute prefix wording.
44.hh/5
correction
Clarified that constants whose values do not belong to their nominal subtype are not static. This change potentially would be incompatible, but this case is considered pathological and will not be checked by the ACATS.

4.9.1 Statically Matching Constraints and Subtypes​

Static Semantics​

1/2

A constraint statically matches another constraint if:

1.1/2
  • both are null constraints;
1.a/5
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.
1.2/21.5/5

The Global or Global'Class aspects (see 6.1.2) of two entities statically match if both consist of a single global_aspect_definition where each is the reserved word null, or each is of the form “global_mode global_designator” with each global_mode being the same sequence of reserved words and each global_designator being the same reserved word, or each being a global_name that statically names the same entity.

2/5

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.

2.a
ramification
Statically matching constraints and subtypes are the basis for subtype conformance of profiles (see 6.3.1).
2.b/2
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.
2.c/5
ramification
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.
2.d/5
discussion
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 ...").
3

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.

3.a
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.
4/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.

4.a
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.
4.b
note
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.
5/3

Two statically matching subtypes are statically compatible with each other. In addition, a subtype S1 is statically compatible with a subtype S2 if:

6/3
  • the constraint of S1 is statically compatible with S2, and
    • 7/3
  • if S2 excludes null, so does S1, and
    • 8/3
  • either:
9/3
  • all predicate specifications that apply to S2 apply also to S1, or
    • 10/4
  • both subtypes are static, every value that satisfies the predicates of S1 also satisfies the predicates 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​

10.a
note
This subclause is new to Ada 95.

Wording Changes from Ada 95​

10.b/2
note
Added static matching rules for null exclusions and anonymous access-to-subprogram types; both of these are new.
10.c/2
note
We clarify that the constraint of the first subtype of a scalar formal type statically matches itself.

Incompatibilities With Ada 2005​

10.d/3
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​

10.e/3
note
Modified static matching and static compatibility to take predicate aspects (see 3.2.4) into account.

Wording Changes from Ada 2012​

10.f/4
note
Corrigendum: Updated wording of static compatibility to use the new term "satisfies the predicates" (see 3.2.4).
10.g/5
note
Updated wording to take nonconfirming values of Object_Size into account.
10.h/5
note
Static matching now includes the effects of Global aspects and the Nonblocking aspect.