4 Names and Expressions
1/3 {AI05-0299-1} [The rules applicable to the different forms of name and
expression, and to their evaluation, are given in this clause.]
4.1 Names
1 [Names can denote declared entities, whether declared explicitly or
implicitly (see 3.1). Names can also denote objects or subprograms designated
by access values; the results of type_conversions or function_calls;
subcomponents and slices of objects and values; protected subprograms, single
entries, entry families, and entries in families of entries. Finally, names
can denote attributes of any of the foregoing.]
Syntax
2/3 {AI05-0003-1} {AI05-0139-2} name ::=
direct_name | explicit_dereference
| indexed_component | slice
| selected_component | attribute_reference
| type_conversion | function_call
| character_literal | qualified_expression
| generalized_reference | generalized_indexing
3 direct_name ::= identifier | operator_symbol
3.a/2 Discussion: {AI95-00114-01} character_literal is no longer a
direct_name. character_literals are usable even when the
corresponding enumeration type declaration is not visible. See
4.2.
4 prefix ::= name | implicit_dereference
5 explicit_dereference ::= name.all
6 implicit_dereference ::= name
7/3 {AI05-0004-1} [Certain forms of name (indexed_components,
selected_components, slices, and attribute_references) include a prefix that
is either itself a name that denotes some related entity, or an
implicit_dereference of an access value that designates some related entity.]
Name Resolution Rules
8 The name in a dereference (either an implicit_dereference or an
explicit_dereference) is expected to be of any access type.
Static Semantics
9/3 {AI05-0008-1} If the type of the name in a dereference is some
access-to-object type T, then the dereference denotes a view of an object, the
nominal subtype of the view being the designated subtype of T. If the
designated subtype has unconstrained discriminants, the (actual) subtype of
the view is constrained by the values of the discriminants of the designated
object, except when there is a partial view of the type of the designated
subtype that does not have discriminants, in which case the dereference is not
constrained by its discriminant values.
9.a Ramification: If the value of the name is the result of an access
type conversion, the dereference denotes a view created as part of
the conversion. The nominal subtype of the view is not necessarily
the same as that used to create the designated object. See 4.6.
9.b To be honest: We sometimes refer to the nominal subtype of a
particular kind of name rather than the nominal subtype of the
view denoted by the name (presuming the name denotes a view of an
object). These two uses of nominal subtype are intended to mean
the same thing.
9.c/3 Reason: {AI05-0008-1} The last sentence was not present in Ada 95;
it is necessary in Ada 2005 because general access types can
designate unconstrained objects, which was not possible in Ada 95.
Thus, the rules that had this effect in Ada 95 (the object being
constrained by its initial value) don't work in Ada 2005 and we
have to say this explicitly.
9.d/3 {AI05-0008-1} The "except" part of the last sentence prevents
privacy "breaking", so that if a private type has discriminants
only in the full view, they don't interfere with freely
interassigning values between objects of the type, even when the
objects live in the heap.
9.e/3 Implementation Note: {AI05-0008-1} Since we don't depend on
whether the designated object is constrained, it is not necessary
to include a constrained bit in every object that could be
designated by a general access type.
10 If the type of the name in a dereference is some access-to-subprogram type
S, then the dereference denotes a view of a subprogram, the profile of the
view being the designated profile of S.
10.a Ramification: This means that the formal parameter names and
default expressions to be used in a call whose name or prefix is a
dereference are those of the designated profile, which need not be
the same as those of the subprogram designated by the access
value, since 'Access requires only subtype conformance, not full
conformance.
Dynamic Semantics
11/2 {AI95-00415-01} The evaluation of a name determines the entity denoted by
the name. This evaluation has no other effect for a name that is a
direct_name or a character_literal.
12 [The evaluation of a name that has a prefix includes the evaluation of the
prefix.] The evaluation of a prefix consists of the evaluation of the name or
the implicit_dereference. The prefix denotes the entity denoted by the name or
the implicit_dereference.
13 The evaluation of a dereference consists of the evaluation of the name and
the determination of the object or subprogram that is designated by the value
of the name. A check is made that the value of the name is not the null access
value. Constraint_Error is raised if this check fails. The dereference denotes
the object or subprogram designated by the value of the name.
Examples
14 Examples of direct names:
15 Pi -- the direct name of a number (see 3.3.2)
Limit -- the direct name of a constant (see 3.3.1)
Count -- the direct name of a scalar variable (see 3.3.1)
Board -- the direct name of an array variable (see 3.6.1)
Matrix -- the direct name of a type (see 3.6)
Random -- the direct name of a function (see 6.1)
Error -- the direct name of an exception (see 11.1)
16 Examples of dereferences:
17 Next_Car.all
-- explicit dereference denoting the object designated by
-- the access variable Next_Car (see 3.10.1)
Next_Car.Owner
-- selected component with implicit dereference;
-- same as Next_Car.all.Owner
Extensions to Ada 83
17.a Type conversions and function calls are now considered names that
denote the result of the operation. In the case of a type
conversion used as an actual parameter or that is of a tagged
type, the type conversion is considered a variable if the operand
is a variable. This simplifies the description of "parameters of
the form of a type conversion" as well as better supporting an
important OOP paradigm that requires the combination of a
conversion from a class-wide type to some specific type followed
immediately by component selection. Function calls are considered
names so that a type conversion of a function call and the
function call itself are treated equivalently in the grammar. A
function call is considered the name of a constant, and can be
used anywhere such a name is permitted. See 6.5.
17.b/1 Type conversions of a tagged type are permitted anywhere their
operand is permitted. That is, if the operand is a variable, then
the type conversion can appear on the left-hand side of an
assignment_statement. If the operand is an object, then the type
conversion can appear in an object renaming or as a prefix. See
4.6.
Wording Changes from Ada 83
17.c/2 {AI95-00114-01} Everything of the general syntactic form name
(...) is now syntactically a name. In any realistic parser, this
would be a necessity since distinguishing among the various name
(...) constructs inevitably requires name resolution. In cases
where the construct yields a value rather than an object, the name
denotes a value rather than an object. Names already denote values
in Ada 83 with named numbers, components of the result of a
function call, etc. This is partly just a wording change, and
partly an extension of functionality (see Extensions heading
above).
17.d The syntax rule for direct_name is new. It is used in places where
direct visibility is required. It's kind of like Ada 83's
simple_name, but simple_name applied to both direct visibility and
visibility by selection, and furthermore, it didn't work right for
operator_symbols. The syntax rule for simple_name is removed,
since its use is covered by a combination of direct_name and
selector_name. The syntactic categories direct_name and
selector_name are similar; it's mainly the visibility rules that
distinguish the two. The introduction of direct_name requires the
insertion of one new explicit textual rule: to forbid
statement_identifiers from being operator_symbols. This is the
only case where the explicit rule is needed, because this is the
only case where the declaration of the entity is implicit. For
example, there is no need to syntactically forbid (say) "X:
"Rem";", because it is impossible to declare a type whose name is an
operator_symbol in the first place.
17.e The syntax rules for explicit_dereference and
implicit_dereference are new; this makes other rules simpler,
since dereferencing an access value has substantially different
semantics from selected_components. We also use name instead of
prefix in the explicit_dereference rule since that seems clearer.
Note that these rules rely on the fact that function calls are now
names, so we don't need to use prefix to allow functions calls in
front of .all.
17.f Discussion: Actually, it would be reasonable to allow any
primary in front of .all, since only the value is needed, but that
would be a bit radical.
17.g We no longer use the term appropriate for a type since we now
describe the semantics of a prefix in terms of implicit
dereference.
Extensions to Ada 2005
17.h/3 {AI05-0003-1} A qualified_expression is now a name denoting a
constant view; this allows them to be used as a prefix and to be
renamed as an object. They are often used to remove ambiguity from
function calls, and there may be no other way to do that.
Interestingly, a type_conversion of a qualified_expression is
already legal in these contexts, so this change mainly reduces
clutter by eliminating an otherwise unneeded type_conversion from
some expressions.
Wording Changes from Ada 2005
17.i/3 {AI05-0008-1} Correction: Added a missing rule so that most
dereferences are assumed constrained (without determining whether
the designated object is). This is just confirming the Ada 95
rules; Ada 2005 failed to ensure that this property was unchanged.
17.j/3 {AI05-0139-2} {AI05-0299-1} Added generalized_reference and
generalized_indexing as types of name; these are documented as
extensions in the appropriate subclauses.
4.1.1 Indexed Components
1 [An indexed_component denotes either a component of an array or an entry
in a family of entries. ]
Syntax
2 indexed_component ::= prefix(expression {, expression})
Name Resolution Rules
3 The prefix of an indexed_component with a given number of expressions
shall resolve to denote an array (after any implicit dereference) with the
corresponding number of index positions, or shall resolve to denote an entry
family of a task or protected object (in which case there shall be only one
expression).
4 The expected type for each expression is the corresponding index type.
Static Semantics
5 When the prefix denotes an array, the indexed_component denotes the
component of the array with the specified index value(s). The nominal subtype
of the indexed_component is the component subtype of the array type.
6 When the prefix denotes an entry family, the indexed_component denotes the
individual entry of the entry family with the specified index value.
Dynamic Semantics
7 For the evaluation of an indexed_component, the prefix and the
expressions are evaluated in an arbitrary order. The value of each
expression is converted to the corresponding index type. A check is made that
each index value belongs to the corresponding index range of the array or
entry family denoted by the prefix. Constraint_Error is raised if this check
fails.
Examples
8 Examples of indexed components:
9 My_Schedule(Sat) -- a component of a one-dimensional array
(see 3.6.1)
Page(10) -- a component of a one-dimensional array
(see 3.6)
Board(M, J + 1) -- a component of a two-dimensional array
(see 3.6.1)
Page(10)(20) -- a component of a component
(see 3.6)
Request(Medium) -- an entry in a family of entries
(see 9.1)
Next_Frame(L)(M, N) -- a component of a function call
(see 6.1)
NOTES
10 1 Notes on the examples: Distinct notations are used for components
of multidimensional arrays (such as Board) and arrays of arrays (such
as Page). The components of an array of arrays are arrays and can
therefore be indexed. Thus Page(10)(20) denotes the 20th component of
Page(10). In the last example Next_Frame(L) is a function call
returning an access value that designates a two-dimensional array.
4.1.2 Slices
1 [ A slice denotes a one-dimensional array formed by a sequence of
consecutive components of a one-dimensional array. A slice of a variable is a
variable; a slice of a constant is a constant;] a slice of a value is a value.
Syntax
2 slice ::= prefix(discrete_range)
Name Resolution Rules
3 The prefix of a slice shall resolve to denote a one-dimensional array
(after any implicit dereference).
4 The expected type for the discrete_range of a slice is the index type of
the array type.
Static Semantics
5 A slice denotes a one-dimensional array formed by the sequence of
consecutive components of the array denoted by the prefix, corresponding to
the range of values of the index given by the discrete_range.
6 The type of the slice is that of the prefix. Its bounds are those defined
by the discrete_range.
Dynamic Semantics
7 For the evaluation of a slice, the prefix and the discrete_range are
evaluated in an arbitrary order. If the slice is not a null slice (a slice
where the discrete_range is a null range), then a check is made that the
bounds of the discrete_range belong to the index range of the array denoted by
the prefix. Constraint_Error is raised if this check fails.
NOTES
8 2 A slice is not permitted as the prefix of an Access
attribute_reference, even if the components or the array as a whole
are aliased. See 3.10.2.
8.a Proof: Slices are not aliased, by 3.10, "Access Types".
8.b Reason: This is to ease implementation of general-access-to-array.
If slices were aliased, implementations would need to store array
dope with the access values, which is not always desirable given
access-to-incomplete types completed in a package body.
9 3 For a one-dimensional array A, the slice A(N .. N) denotes an array
that has only one component; its type is the type of A. On the other
hand, A(N) denotes a component of the array A and has the
corresponding component type.
Examples
10 Examples of slices:
11 Stars(1 .. 15) -- a slice of 15 characters
(see 3.6.3)
Page(10 .. 10 + Size) -- a slice of 1 + Size components
(see 3.6)
Page(L)(A .. B) -- a slice of the array Page(L)
(see 3.6)
Stars(1 .. 0) -- a null slice
(see 3.6.3)
My_Schedule(Weekday) -- bounds given by subtype
(see 3.6.1 and 3.5.1)
Stars(5 .. 15)(K) -- same as Stars(K)
(see 3.6.3)
-- provided that K is in 5 .. 15
4.1.3 Selected Components
1 [Selected_components are used to denote components (including
discriminants), entries, entry families, and protected subprograms; they are
also used as expanded names as described below. ]
Syntax
2 selected_component ::= prefix . selector_name
3 selector_name ::= identifier | character_literal | operator_symbol
Name Resolution Rules
4 A selected_component is called an expanded name if, according to the
visibility rules, at least one possible interpretation of its prefix denotes a
package or an enclosing named construct (directly, not through a
subprogram_renaming_declaration or generic_renaming_declaration).
4.a Discussion: See AI83-00187.
5 A selected_component that is not an expanded name shall resolve to denote
one of the following:
5.a Ramification: If the prefix of a selected_component denotes an
enclosing named construct, then the selected_component is
interpreted only as an expanded name, even if the named construct
is a function that could be called without parameters.
6 * A component [(including a discriminant)]:
7 The prefix shall resolve to denote an object or value of some
non-array composite type (after any implicit dereference). The
selector_name shall resolve to denote a discriminant_specification of
the type, or, unless the type is a protected type, a
component_declaration of the type. The selected_component denotes the
corresponding component of the object or value.
7.a/3 Reason: {AI05-0005-1} The components of a protected object cannot
be named except by an expanded name, even from within the
corresponding protected body. The protected body cannot reference
the private components of some arbitrary object of the protected
type; the protected body may reference components of the current
instance only (by an expanded name or a direct_name).
7.b Ramification: Only the discriminants and components visible at the
place of the selected_component can be selected, since a
selector_name can only denote declarations that are visible (see
8.3).
8 * A single entry, an entry family, or a protected subprogram:
9 The prefix shall resolve to denote an object or value of some task or
protected type (after any implicit dereference). The selector_name
shall resolve to denote an entry_declaration or
subprogram_declaration occurring (implicitly or explicitly) within the
visible part of that type. The selected_component denotes the
corresponding entry, entry family, or protected subprogram.
9.a Reason: This explicitly says "visible part" because even though
the body has visibility on the private part, it cannot call the
private operations of some arbitrary object of the task or
protected type, only those of the current instance (and expanded
name notation has to be used for that).
9.1/2 * {AI95-00252-01} {AI95-00407-01} A view of a subprogram whose first
formal parameter is of a tagged type or is an access parameter whose
designated type is tagged:
9.2/3 {AI95-00252-01} {AI95-00407-01} {AI05-0090-1} The prefix (after any
implicit dereference) shall resolve to denote an object or value of a
specific tagged type T or class-wide type T'Class. The selector_name
shall resolve to denote a view of a subprogram declared immediately
within the declarative region in which an ancestor of the type T is
declared. The first formal parameter of the subprogram shall be of
type T, or a class-wide type that covers T, or an access parameter
designating one of these types. The designator of the subprogram shall
not be the same as that of a component of the tagged type visible at
the point of the selected_component. The subprogram shall not be an
implicitly declared primitive operation of type T that overrides an
inherited subprogram implemented by an entry or protected subprogram
visible at the point of the selected_component. The
selected_component denotes a view of this subprogram that omits the
first formal parameter. This view is called a prefixed view of the
subprogram, and the prefix of the selected_component (after any
implicit dereference) is called the prefix of the prefixed view.
9.b/3 Discussion: {AI05-0090-1} The part of the rule that excludes a
primitive overriding subprogram as a selector applies only to the
wrapper subprogram that is implicitly declared to override a
subprogram inherited from a synchronized interface that is
implemented by an operation of a task or protected type (see 9.1
and 9.4). We don't want calls that use a prefixed view to be
ambiguous between the wrapper subprogram and the implementing
entry or protected operation. Note that it is illegal to declare
an explicit primitive that has a prefixed view that is homographic
with one of the type's operations, so in normal cases it isn't
possible to have an ambiguity in a prefix call. However, a
class-wide operation of an ancestor type that is declared in the
same declaration list with the ancestor type is also considered,
and that can still make a call ambiguous.
10 An expanded name shall resolve to denote a declaration that occurs
immediately within a named declarative region, as follows:
11 * The prefix shall resolve to denote either a package [(including the
current instance of a generic package, or a rename of a package)], or
an enclosing named construct.
12 * The selector_name shall resolve to denote a declaration that occurs
immediately within the declarative region of the package or enclosing
construct [(the declaration shall be visible at the place of the
expanded name - see 8.3)]. The expanded name denotes that declaration.
12.a Ramification: Hence, a library unit or subunit can use an expanded
name to refer to the declarations within the private part of its
parent unit, as well as to other children that have been mentioned
in with_clauses.
13 * If the prefix does not denote a package, then it shall be a
direct_name or an expanded name, and it shall resolve to denote a
program unit (other than a package), the current instance of a type, a
block_statement, a loop_statement, or an accept_statement (in the case
of an accept_statement or entry_body, no family index is allowed); the
expanded name shall occur within the declarative region of this
construct. Further, if this construct is a callable construct and the
prefix denotes more than one such enclosing callable construct, then
the expanded name is ambiguous, independently of the selector_name.
Legality Rules
13.1/2 {AI95-00252-01} {AI95-00407-01} For a subprogram whose first parameter
is an access parameter, the prefix of any prefixed view shall denote an
aliased view of an object.
13.2/2 {AI95-00407-01} For a subprogram whose first parameter is of mode in
out or out, or of an anonymous access-to-variable type, the prefix of any
prefixed view shall denote a variable.
13.a/2 Reason: We want calls through a prefixed view and through a normal
view to have the same legality. Thus, the implicit 'Access in this
new notation needs the same legality check that an explicit
'Access would have. Similarly, we need to prohibit the object from
being constant if the first parameter of the subprogram is in out,
because that is (obviously) prohibited for passing a normal
parameter.
Dynamic Semantics
14 The evaluation of a selected_component includes the evaluation of the
prefix.
15 For a selected_component that denotes a component of a variant, a check is
made that the values of the discriminants are such that the value or object
denoted by the prefix has this component. The exception Constraint_Error is
raised if this check fails.
Examples
16 Examples of selected components:
17/2 {AI95-00252-01} {AI95-00407-01}
Tomorrow.Month -- a record component
(see 3.8)
Next_Car.Owner -- a record component
(see 3.10.1)
Next_Car.Owner.Age -- a record component
(see 3.10.1)
-- the previous two lines involve implicit dereferences
Writer.Unit -- a record component (a discriminant)
(see 3.8.1)
Min_Cell(H).Value -- a record component of the result
(see 6.1)
-- of the function call Min_Cell(H)
Cashier.Append -- a prefixed view of a procedure
(see 3.9.4)
Control.Seize -- an entry of a protected object
(see 9.4)
Pool(K).Write -- an entry of the task Pool(K)
(see 9.4)
18 Examples of expanded names:
19 Key_Manager."<" -- an operator of the visible part of a package
(see 7.3.1)
Dot_Product.Sum -- a variable declared in a function body
(see 6.1)
Buffer.Pool -- a variable declared in a protected unit
(see 9.11)
Buffer.Read -- an entry of a protected unit
(see 9.11)
Swap.Temp -- a variable declared in a block statement
(see 5.6)
Standard.Boolean -- the name of a predefined type
(see A.1)
Extensions to Ada 83
19.a We now allow an expanded name to use a prefix that denotes a
rename of a package, even if the selector is for an entity local
to the body or private part of the package, so long as the entity
is visible at the place of the reference. This eliminates a
preexisting anomaly where references in a package body may refer
to declarations of its visible part but not those of its private
part or body when the prefix is a rename of the package.
Wording Changes from Ada 83
19.b The syntax rule for selector_name is new. It is used in places
where visibility, but not necessarily direct visibility, is
required. See 4.1, "Names" for more information.
19.c The description of dereferencing an access type has been moved to
4.1, "Names"; name.all is no longer considered a
selected_component.
19.d The rules have been restated to be consistent with our new
terminology, to accommodate class-wide types, etc.
Extensions to Ada 95
19.e/2 {AI95-00252-01} The prefixed view notation for tagged objects is
new. This provides a similar notation to that used in other
popular languages, and also reduces the need for use_clauses. This
is sometimes known as "distinguished receiver notation".
19.f/2 Given the following definitions for a tagged type T:
19.g/2 procedure Do_Something (Obj : in out T; Count : in Natural);
procedure Do_Something_Else (Obj : access T; Flag : in Boolean);
My_Object : aliased T;
19.h/2 the following calls are equivalent:
19.i/2 Do_Something (My_Object, Count => 10);
My_Object.Do_Something (Count => 10);
19.j/2 as are the following calls:
19.k/2 Do_Something_Else (My_Object'Access, Flag => True);
My_Object.Do_Something_Else (Flag => True);
Wording Changes from Ada 2005
19.l/3 {AI05-0090-1} Correction: Corrected the definition of a prefixed
view to ignore the implicit subprograms declared for "implemented
by" entries and protected subprograms.
4.1.4 Attributes
1 [An attribute is a characteristic of an entity that can be queried via an
attribute_reference or a range_attribute_reference.]
Syntax
2 attribute_reference ::= prefix'attribute_designator
3/2 {AI05-0004-1} attribute_designator ::=
identifier[(static_expression)]
| Access | Delta | Digits | Mod
4 range_attribute_reference ::= prefix'range_attribute_designator
5 range_attribute_designator ::= Range[(static_expression)]
Name Resolution Rules
6 In an attribute_reference, if the attribute_designator is for an attribute
defined for (at least some) objects of an access type, then the prefix is
never interpreted as an implicit_dereference; otherwise (and for all
range_attribute_references), if the type of the name within the prefix is of
an access type, the prefix is interpreted as an implicit_dereference.
Similarly, if the attribute_designator is for an attribute defined for (at
least some) functions, then the prefix is never interpreted as a parameterless
function_call; otherwise (and for all range_attribute_references), if the
prefix consists of a name that denotes a function, it is interpreted as a
parameterless function_call.
6.a Discussion: The first part of this rule is essentially a
"preference" against implicit dereference, so that it is possible
to ask for, say, 'Size of an access object, without automatically
getting the size of the object designated by the access object.
This rule applies to 'Access, 'Unchecked_Access, 'Size, and
'Address, and any other attributes that are defined for at least
some access objects.
6.b The second part of this rule implies that, for a parameterless
function F, F'Address is the address of F, whereas F'Size is the
size of the anonymous constant returned by F.
6.c/1 We normally talk in terms of expected type or profile for name
resolution rules, but we don't do this for attributes because
certain attributes are legal independent of the type or the
profile of the prefix.
6.d/2 {AI95-00114-01} Other than the rules given above, the
Name Resolution Rules for the prefix of each attribute are defined
as Name Resolution Rules for that attribute. If no such rules are
defined, then no context at all should be used when resolving the
prefix. In particular, any knowledge about the kind of entities
required must not be used for resolution unless that is required
by Name Resolution Rules. This matters in obscure cases; for
instance, given the following declarations:
6.e/2 function Get_It return Integer is ... -- (1)
function Get_It return Some_Record_Type is ... -- (2)
6.f/2 the following attribute_reference cannot be resolved and is
illegal:
6.g/2 if Get_It'Valid then
6.h/3 {AI05-0005-1} even though the Valid attribute is only defined for
objects of scalar types, and thus cannot be applied to the result
of function (2). That information cannot be used to resolve the
prefix. The same would be true if (2) had been a procedure; even
though the procedure does not denote an object, the
attribute_reference is still illegal.
7 The expression, if any, in an attribute_designator or
range_attribute_designator is expected to be of any integer type.
Legality Rules
8 The expression, if any, in an attribute_designator or
range_attribute_designator shall be static.
Static Semantics
9/4 {AI05-0006-1} {AI12-0032-1} {AI12-0159-1} An attribute_reference denotes a
value, an object, a subprogram, or some other kind of program entity. Unless
explicitly specified otherwise, for an attribute_reference that denotes a
value or an object, if its type is scalar, then its nominal subtype is the
base subtype of the type; if its type is tagged, its nominal subtype is the
first subtype of the type; otherwise, its nominal subtype is a subtype of the
type without any constraint, null_exclusion, or predicate. Similarly, unless
explicitly specified otherwise, for an attribute_reference that denotes a
function, when its result type is scalar, its result subtype is the base
subtype of the type, when its result type is tagged, the result subtype is the
first subtype of the type, and when the result type is some other type, the
result subtype is a subtype of the type without any constraint,
null_exclusion, or predicate.
9.a Ramification: The attributes defined by the language are
summarized in K.2. Implementations can define additional
attributes.
9.b/3 Discussion: {AI05-0006-1} The nominal subtype is primarily a
concern when an attribute_reference, or a call on an
attribute_reference, is used as the expression of a case
statement, due to the full coverage requirement based on the
nominal subtype. For nondiscrete cases, we define the nominal
subtype mainly for completeness. Implementations may specify
otherwise for implementation-defined attribute functions.
9.c/3 The rule is written to match the meaning of the italicized T in
the definition of attributes such as Input; see 4.5.1.
9.d/3 To be honest: {AI05-0006-1} We don't worry about the fact that "
base subtype" is not explicitly defined for the universal types.
Since it is not possible to constrain a universal numeric type,
all subtypes are unconstrained, and hence can be considered base
subtypes. The wording above could be altered to bypass this issue,
but it doesn't seem necessary, since universal integer is handled
specially in the rules for case expression full coverage, and we
don't allow user-defined functions for attribute functions whose
result type is universal.
10 [A range_attribute_reference X'Range(N) is equivalent to the range
X'First(N) .. X'Last(N), except that the prefix is only evaluated once.
Similarly, X'Range is equivalent to X'First .. X'Last, except that the
prefix is only evaluated once.]
Dynamic Semantics
11 The evaluation of an attribute_reference (or range_attribute_reference)
consists of the evaluation of the prefix.
Implementation Permissions
12/1 {8652/0015} {AI95-00093-01} An implementation may provide
implementation-defined attributes; the identifier for an
implementation-defined attribute shall differ from those of the
language-defined attributes unless supplied for compatibility with a previous
edition of this International Standard.
12.a Implementation defined: Implementation-defined attributes.
12.b Ramification: They cannot be reserved words because reserved words
are not legal identifiers.
12.c The semantics of implementation-defined attributes, and any
associated rules, are, of course, implementation defined. For
example, the implementation defines whether a given
implementation-defined attribute can be used in a static
expression.
12.c.1/1 {8652/0015} {AI95-00093-01} Implementations are allowed to support
the Small attribute for floating types, as this was defined in Ada
83, even though the name would conflict with a language-defined
attribute.
NOTES
13 4 Attributes are defined throughout this International Standard, and
are summarized in K.2.
14/2 5 {AI95-00235} In general, the name in a prefix of an
attribute_reference (or a range_attribute_reference) has to be
resolved without using any context. However, in the case of the Access
attribute, the expected type for the attribute_reference has to be a
single access type, and the resolution of the name can use the fact
that the type of the object or the profile of the callable entity
denoted by the prefix has to match the designated type or be type
conformant with the designated profile of the access type.
14.a/2 Proof: {AI95-00235} In the general case, there is no "expected
type" for the prefix of an attribute_reference. In the special case of
'Access, there is an "expected type" or "expected profile" for the
prefix.
14.b Reason: 'Access is a special case, because without it, it would be
very difficult to take 'Access of an overloaded subprogram.
Examples
15 Examples of attributes:
16 Color'First -- minimum value of the enumeration type Color
(see 3.5.1)
Rainbow'Base'First -- same as Color'First
(see 3.5.1)
Real'Digits -- precision of the type Real
(see 3.5.7)
Board'Last(2) -- upper bound of the second dimension of Board
(see 3.6.1)
Board'Range(1) -- index range of the first dimension of Board
(see 3.6.1)
Pool(K)'Terminated -- True if task Pool(K) is terminated
(see 9.1)
Date'Size -- number of bits for records of type Date
(see 3.8)
Message'Address -- address of the record variable Message
(see 3.7.1)
Extensions to Ada 83
16.a We now uniformly treat X'Range as X'First..X'Last, allowing its
use with scalar subtypes.
16.b We allow any integer type in the static_expression of an attribute
designator, not just a value of universal_integer. The preference
rules ensure upward compatibility.
Wording Changes from Ada 83
16.c We use the syntactic category attribute_reference rather than
simply "attribute" to avoid confusing the name of something with
the thing itself.
16.d The syntax rule for attribute_reference now uses identifier
instead of simple_name, because attribute identifiers are not
required to follow the normal visibility rules.
16.e We now separate attribute_reference from
range_attribute_reference, and enumerate the reserved words that
are legal attribute or range attribute designators. We do this
because identifier no longer includes reserved words.
16.f The Ada 95 name resolution rules are a bit more explicit than in
Ada 83. The Ada 83 rule said that the "meaning of the prefix of an
attribute must be determinable independently of the attribute
designator and independently of the fact that it is the prefix of
an attribute." That isn't quite right since the meaning even in
Ada 83 embodies whether or not the prefix is interpreted as a
parameterless function call, and in Ada 95, it also embodies
whether or not the prefix is interpreted as an
implicit_dereference. So the attribute designator does make a
difference - just not much.
16.g Note however that if the attribute designator is Access, it makes
a big difference in the interpretation of the prefix (see 3.10.2
).
Wording Changes from Ada 95
16.h/2 {8652/0015} {AI95-00093-01} Corrigendum: The wording was changed
to allow implementations to continue to implement the Ada 83 Small
attribute. This was always intended to be allowed.
16.i/2 {AI95-00235-01} The note about resolving prefixes of attributes
was updated to reflect that the prefix of an Access attribute now
has an expected type (see 3.10.2).
Wording Changes from Ada 2005
16.j/3 {AI05-0006-1} Correction: Defined the nominal subtype of an
attribute_reference to close a minor language hole.
Wording Changes from Ada 2012
16.k/4 {AI12-0032-1} Corrigendum: Allowed overriding the nominal subtype
of an attribute_reference for an object; that is used elsewhere in
this standard.
16.l/4 {AI12-0159-1} Corrigendum: Added wording so it is clear that
predicates don't apply to the result of an attribute.
4.1.5 User-Defined References
Static Semantics
1/3 {AI05-0139-2} Given a discriminated type T, the following type-related
operational aspect may be specified:
2/3 Implicit_Dereference
This aspect is specified by a name that denotes an access
discriminant declared for the type T.
2.a/3 Aspect Description for Implicit_Dereference: Mechanism for
user-defined implicit .all.
3/3 {AI05-0139-2} A (view of a) type with a specified Implicit_Dereference
aspect is a reference type. A reference object is an object of a reference
type. The discriminant named by the Implicit_Dereference aspect is the
reference discriminant of the reference type or reference object. [A
generalized_reference is a name that identifies a reference object, and
denotes the object or subprogram designated by the reference discriminant of
the reference object.]
3.a.1/3 Glossary entry: A reference type is one that has user-defined
behavior for ".all", defined by the Implicit_Dereference aspect.
Syntax
4/3 {AI05-0139-2} generalized_reference ::= reference_object_name
Name Resolution Rules
5/3 {AI05-0139-2} {AI05-0269-1} The expected type for the
reference_object_name in a generalized_reference is any reference type.
Static Semantics
5.1/4 {AI12-0138-1} The Implicit_Dereference aspect is nonoverridable (see
13.1.1).
5.a/4 Reason: This ensures that all descendants of a reference type have
the same reference discriminant. This prevents generic contract
problems with formal derived types.
6/3 {AI05-0139-2} A generalized_reference denotes a view equivalent to that of
a dereference of the reference discriminant of the reference object.
7/3 {AI05-0139-2} Given a reference type T, the Implicit_Dereference aspect is
inherited by descendants of type T if not overridden. If a descendant type
constrains the value of the reference discriminant of T by a new discriminant,
that new discriminant is the reference discriminant of the descendant. [If the
descendant type constrains the value of the reference discriminant of T by an
expression other than the name of a new discriminant, a
generalized_reference that identifies an object of the descendant type denotes
the object or subprogram designated by the value of this constraining
expression.]
Dynamic Semantics
8/3 {AI05-0139-2} The evaluation of a generalized_reference consists of the
evaluation of the reference_object_name and a determination of the object or
subprogram designated by the reference discriminant of the named reference
object. A check is made that the value of the reference discriminant is not
the null access value. Constraint_Error is raised if this check fails. The
generalized_reference denotes the object or subprogram designated by the value
of the reference discriminant of the named reference object.
Examples
9/3 {AI05-0268-1}
type Barrel is tagged ... -- holds objects of type Element
10/3 {AI05-0139-2} {AI05-0299-1}
type Ref_Element(Data : access Element) is limited private
with Implicit_Dereference => Data;
-- This Ref_Element type is a "reference" type.
-- "Data" is its reference discriminant.
11/3 {AI05-0139-2} {AI05-0268-1}
function Find (B : aliased in out Barrel; Key : String) return Ref_Element;
-- Return a reference to an element of a barrel.
12/3 {AI05-0268-1} {AI05-0299-1} B: aliased Barrel;
13/3 {AI05-0139-2} ...
14/3 {AI05-0139-2} {AI05-0268-1}
Find (B, "grape") := Element'(...); -- Assign through a reference.
15/3 {AI05-0139-2} {AI05-0268-1} -- This is equivalent to:
Find (B, "grape").Data.all := Element'(...);
Extensions to Ada 2005
15.a/3 {AI05-0139-2} The aspect Implicit_Dereference and the
generalized_reference are new.
Incompatibilities With Ada 2012
15.b/4 {AI12-0138-1} Corrigendum: Defined Implicit_Dereference to be
nonoveridable, which makes redefinitions and hiding of the aspect
illegal. It's possible that some program could violate one of
these new restrictions, but this is not very likely as reference
types are not likely to be used in a hierarchy.
4.1.6 User-Defined Indexing
Static Semantics
1/3 {AI05-0139-2} Given a tagged type T, the following type-related,
operational aspects may be specified:
2/3 Constant_Indexing
This aspect shall be specified by a name that denotes one or
more functions declared immediately within the same
declaration list in which T is declared. All such functions
shall have at least two parameters, the first of which is of
type T or T'Class, or is an access-to-constant parameter with
designated type T or T'Class.
2.a/3 Aspect Description for Constant_Indexing: Defines function(s) to
implement user-defined indexed_components.
3/3 Variable_Indexing
This aspect shall be specified by a name that denotes one or
more functions declared immediately within the same
declaration list in which T is declared. All such functions
shall have at least two parameters, the first of which is of
type T or T'Class, or is an access parameter with designated
type T or T'Class. All such functions shall have a return type
that is a reference type (see 4.1.5), whose reference
discriminant is of an access-to-variable type.
3.a/3 Reason: We require these functions to return a reference type so
that the object returned from the function can act like a
variable. We need no similar rule for Constant_Indexing, since all
functions return constant objects.
3.b/3 Aspect Description for Variable_Indexing: Defines function(s) to
implement user-defined indexed_components.
4/4 {AI12-0104-1} These aspects are inherited by descendants of T (including
the class-wide type T'Class).
4.a/3 Ramification: Indexing can be provided for multiple index types by
overloading routines with different parameter profiles. For
instance, the map containers provide indexing on both cursors and
keys by providing pairs of overloaded routines to the
Constant_Indexing and Variable_Indexing aspects.
5/3 {AI05-0139-2} {AI05-0292-1} An indexable container type is (a view of) a
tagged type with at least one of the aspects Constant_Indexing or
Variable_Indexing specified. An indexable container object is an object of an
indexable container type. [A generalized_indexing is a name that denotes the
result of calling a function named by a Constant_Indexing or Variable_Indexing
aspect.]
5.a.1/3 Glossary entry: An indexable container type is one that has
user-defined behavior for indexing, via the Constant_Indexing or
Variable_Indexing aspects.
5.1/4 {AI12-0138-1} The Constant_Indexing and Variable_Indexing aspects are
nonoverridable (see 13.1.1).
5.a/4 Reason: This ensures that all descendants of an indexable
container type have aspects with the same properties. This
prevents generic contract problems with formal derived types.
5.b/4 {AI12-0104-1} {AI12-0138-1} A nonoverridable aspect allows the
replacement of the implementation of an indexing function and the
addition of a new indexing function for a derived type, but not
the removal of an indexing function. This is necessary so that
indexing can be used on objects of T'Class. So long as the tag of
O is that of its nominal subtype, we do not want T'Class(O)(I) to
mean something different than O(I). Thus we cannot allow a change
in the function identified. As T'Class(O)(I) expands into a
dispatching call, we need to ensure that there is a body for each
such function -- but it is OK for that body to be changed from the
original body (that's just normal dispatching).
Paragraphs 6 through 9 were deleted.
Syntax
10/3 {AI05-0139-2} {AI05-0292-1} generalized_indexing ::=
indexable_container_object_prefix actual_parameter_part
Name Resolution Rules
11/3 {AI05-0139-2} {AI05-0292-1} The expected type for the
indexable_container_object_prefix of a generalized_indexing is any indexable
container type.
12/3 {AI05-0139-2} {AI05-0292-1} If the Constant_Indexing aspect is specified
for the type of the indexable_container_object_prefix of a
generalized_indexing, then the generalized_indexing is interpreted as a
constant indexing under the following circumstances:
13/3 * when the Variable_Indexing aspect is not specified for the type of
the indexable_container_object_prefix;
14/3 * when the indexable_container_object_prefix denotes a constant;
15/3 * when the generalized_indexing is used within a primary where a name
denoting a constant is permitted.
15.a/3 Ramification: This means it is not interpreted as a constant
indexing for the variable_name in the LHS of an assignment (not
inside a primary), nor for the name used for an out or in out
parameter (not allowed to be a constant), nor for the name in an
object renaming (not inside a primary), unless there is no
Variable_Indexing aspect defined.
16/3 Otherwise, the generalized_indexing is interpreted as a variable indexing.
17/3 When a generalized_indexing is interpreted as a constant (or variable)
indexing, it is equivalent to a call on a prefixed view of one of the
functions named by the Constant_Indexing (or Variable_Indexing) aspect of the
type of the indexable_container_object_prefix with the given
actual_parameter_part, and with the indexable_container_object_prefix as the
prefix of the prefixed view.
17.a/3 Ramification: In other words, the generalized_indexing is
equivalent to:
17.b/3 indexable_container_object_prefix
.Indexing actual_parameter_part
17.c/4 {AI12-0005-1} where Indexing is the name specified for the
Constant_Indexing or Variable_Indexing aspect. This equivalence is
then resolved in the normal way; the aspect specifies a name, it
does not denote declarations.
NOTES
18/4 6 {AI12-0104-1} The Constant_Indexing and Variable_Indexing aspects
cannot be redefined when inherited for a derived type, but the
functions that they denote can be modified by overriding or
overloading.
Examples
19/3 {AI05-0268-1} {AI05-0292-1} type Indexed_Barrel is tagged ...
with Variable_Indexing => Find;
-- Indexed_Barrel is an indexable container type,
-- Find is the generalized indexing operation.
20/3 {AI05-0268-1}
function Find (B : aliased in out Indexed_Barrel; Key : String) return Ref_Element;
-- Return a reference to an element of a barrel (see 4.1.5).
21/3 {AI05-0268-1} IB: aliased Indexed_Barrel;
22/3 {AI05-0268-1} -- All of the following calls are then equivalent:
Find (IB,"pear").Data.all := Element'(...); -- Traditional call
IB.Find ("pear").Data.all := Element'(...); -- Call of prefixed view
IB.Find ("pear") := Element'(...); -- Implicit dereference (see 4.1.5
)
IB ("pear") := Element'(...); -- Implicit indexing and dereference
IB ("pear").Data.all := Element'(...); -- Implicit indexing only
Extensions to Ada 2005
22.a/3 {AI05-0139-2} Aspects Constant_Indexing and Variable_Indexing, and
the generalized_indexing syntax are new.
Wording Changes from Ada 2012
22.b/4 {AI12-0104-1} Corrigendum: Converted confusing and unnecessary
normative wording about "overriding an aspect" into a note.
22.c/4 {AI12-0138-1} Corrigendum: Defined Constant_Indexing and
Variable_Indexing to be nonoveridable. This is merely a new
description for Legality Rules which already applied to these
aspects.
4.2 Literals
1 [ A literal represents a value literally, that is, by means of notation
suited to its kind.] A literal is either a numeric_literal, a
character_literal, the literal null, or a string_literal.
1.a Discussion: An enumeration literal that is an identifier rather
than a character_literal is not considered a literal in the above
sense, because it involves no special notation "suited to its
kind." It might more properly be called an enumeration_identifier,
except for historical reasons.
Name Resolution Rules
2/2 This paragraph was deleted.{AI95-00230-01}
3 For a name that consists of a character_literal, either its expected type
shall be a single character type, in which case it is interpreted as a
parameterless function_call that yields the corresponding value of the
character type, or its expected profile shall correspond to a parameterless
function with a character result type, in which case it is interpreted as the
name of the corresponding parameterless function declared as part of the
character type's definition (see 3.5.1). In either case, the
character_literal denotes the enumeration_literal_specification.
3.a Discussion: See 4.1.3 for the resolution rules for a
selector_name that is a character_literal.
4 The expected type for a primary that is a string_literal shall be a single
string type.
Legality Rules
5 A character_literal that is a name shall correspond to a
defining_character_literal of the expected type, or of the result type of the
expected profile.
6 For each character of a string_literal with a given expected string type,
there shall be a corresponding defining_character_literal of the component
type of the expected string type.
7/2 This paragraph was deleted.{AI95-00230-01} {AI95-00231-01}
Static Semantics
8/2 {AI95-00230-01} An integer literal is of type universal_integer. A real
literal is of type universal_real. The literal null is of type
universal_access.
Dynamic Semantics
9 The evaluation of a numeric literal, or the literal null, yields the
represented value.
10 The evaluation of a string_literal that is a primary yields an array value
containing the value of each character of the sequence of characters of the
string_literal, as defined in 2.6. The bounds of this array value are
determined according to the rules for positional_array_aggregates (see 4.3.3
), except that for a null string literal, the upper bound is the predecessor
of the lower bound.
11 For the evaluation of a string_literal of type T, a check is made that the
value of each character of the string_literal belongs to the component subtype
of T. For the evaluation of a null string literal, a check is made that its
lower bound is greater than the lower bound of the base range of the index
type. The exception Constraint_Error is raised if either of these checks
fails.
11.a Ramification: The checks on the characters need not involve more
than two checks altogether, since one need only check the
characters of the string with the lowest and highest position
numbers against the range of the component subtype.
NOTES
12 7 Enumeration literals that are identifiers rather than
character_literals follow the normal rules for identifiers when used
in a name (see 4.1 and 4.1.3). Character_literals used as
selector_names follow the normal rules for expanded names (see 4.1.3
).
Examples
13 Examples of literals:
14 3.14159_26536 -- a real literal
1_345 -- an integer literal
'A' -- a character literal
"Some Text" -- a string literal
Incompatibilities With Ada 83
14.a Because character_literals are now treated like other literals, in
that they are resolved using context rather than depending on
direct visibility, additional qualification might be necessary
when passing a character_literal to an overloaded subprogram.
Extensions to Ada 83
14.b Character_literals are now treated analogously to null and
string_literals, in that they are resolved using context, rather
than their content; the declaration of the corresponding
defining_character_literal need not be directly visible.
Wording Changes from Ada 83
14.c Name Resolution rules for enumeration literals that are not
character_literals are not included anymore, since they are
neither syntactically nor semantically "literals" but are rather
names of parameterless functions.
Extensions to Ada 95
14.d/2 {AI95-00230-01} {AI95-00231-01} Null now has type
universal_access, which is similar to other literals. Null can be
used with anonymous access types.
4.3 Aggregates
1 [ An aggregate combines component values into a composite value of an
array type, record type, or record extension.]
Syntax
2 aggregate ::= record_aggregate | extension_aggregate
| array_aggregate
Name Resolution Rules
3/2 {AI95-00287-01} The expected type for an aggregate shall be a single array
type, record type, or record extension.
3.a Discussion: See 8.6, "The Context of Overload Resolution" for the
meaning of "shall be a single ... type."
3.b/3 Ramification: {AI05-0005-1} There are additional rules for each
kind of aggregate. These aggregate rules are additive; a legal
expression needs to satisfy all of the applicable rules. That
means the rule given here must be satisfied even when it is
syntactically possible to tell which specific kind of aggregate is
being used.
Legality Rules
4 An aggregate shall not be of a class-wide type.
4.a Ramification: When the expected type in some context is
class-wide, an aggregate has to be explicitly qualified by the
specific type of value to be created, so that the expected type
for the aggregate itself is specific.
4.b Discussion: We used to disallow aggregates of a type with unknown
discriminants. However, that was unnecessarily restrictive in the
case of an extension aggregate, and irrelevant to a record
aggregate (since a type that is legal for a record aggregate could
not possibly have unknown discriminants) and to an array aggregate
(the only specific types that can have unknown discriminants are
private types, private extensions, and types derived from them).
Dynamic Semantics
5 For the evaluation of an aggregate, an anonymous object is created and
values for the components or ancestor part are obtained (as described in the
subsequent subclause for each kind of the aggregate) and assigned into the
corresponding components or ancestor part of the anonymous object. Obtaining
the values and the assignments occur in an arbitrary order. The value of the
aggregate is the value of this object.
5.a Discussion: The ancestor part is the set of components inherited
from the ancestor type. The syntactic category ancestor_part is
the expression or subtype_mark that specifies how the ancestor
part of the anonymous object should be initialized.
5.b Ramification: The assignment operations do the necessary value
adjustment, as described in 7.6. Note that the value as a whole is
not adjusted - just the subcomponents (and ancestor part, if any).
7.6 also describes when this anonymous object is finalized.
5.c If the ancestor_part is a subtype_mark the Initialize procedure
for the ancestor type is applied to the ancestor part after
default-initializing it, unless the procedure is abstract, as
described in 7.6. The Adjust procedure for the ancestor type is
not called in this case, since there is no assignment to the
ancestor part as a whole.
6 If an aggregate is of a tagged type, a check is made that its value
belongs to the first subtype of the type. Constraint_Error is raised if this
check fails.
6.a Ramification: This check ensures that no values of a tagged type
are ever outside the first subtype, as required for inherited
dispatching operations to work properly (see 3.4). This check will
always succeed if the first subtype is unconstrained. This check
is not extended to untagged types to preserve upward
compatibility.
Extensions to Ada 83
6.b We now allow extension_aggregates.
Wording Changes from Ada 83
6.c We have adopted new wording for expressing the rule that the type
of an aggregate shall be determinable from the outside, though
using the fact that it is nonlimited record (extension) or array.
6.d An aggregate now creates an anonymous object. This is necessary so
that controlled types will work (see 7.6).
Incompatibilities With Ada 95
6.e/2 {AI95-00287-01} In Ada 95, a limited type is not considered when
resolving an aggregate. Since Ada 2005 now allows limited
aggregates, we can have incompatibilities. For example:
6.f/2 type Lim is limited
record
Comp: Integer;
end record;
6.g/2 type Not_Lim is
record
Comp: Integer;
end record;
6.h/2 procedure P(X: Lim);
procedure P(X: Not_Lim);
6.i/2 P((Comp => 123)); -- Illegal in Ada 2005, legal in Ada 95
6.j/2 The call to P is ambiguous in Ada 2005, while it would not be
ambiguous in Ada 95 as the aggregate could not have a limited
type. Qualifying the aggregate will eliminate any ambiguity. This
construction would be rather confusing to a maintenance
programmer, so it should be avoided, and thus we expect it to be
rare.
Extensions to Ada 95
6.k/2 {AI95-00287-01} Aggregates can be of a limited type.
4.3.1 Record Aggregates
1 [In a record_aggregate, a value is specified for each component of the
record or record extension value, using either a named or a positional
association.]
Syntax
2 record_aggregate ::= (record_component_association_list)
3 record_component_association_list ::=
record_component_association {, record_component_association}
| null record
4/2 {AI95-00287-01} record_component_association ::=
[component_choice_list =>] expression
| component_choice_list => <>
5 component_choice_list ::=
component_selector_name {| component_selector_name}
| others
6 A record_component_association is a named component association if it
has a component_choice_list; otherwise, it is a positional component
association. Any positional component associations shall precede any
named component associations. If there is a named association with a
component_choice_list of others, it shall come last.
6.a Discussion: These rules were implied by the BNF in an early
version of the RM9X, but it made the grammar harder to read, and
was inconsistent with how we handle discriminant constraints. Note
that for array aggregates we still express some of the rules in
the grammar, but array aggregates are significantly different
because an array aggregate is either all positional (with a
possible others at the end), or all named.
7 In the record_component_association_list for a record_aggregate, if
there is only one association, it shall be a named association.
7.a/3 Reason: {AI05-0264-1} Otherwise, the construct would be
interpreted as a parenthesized expression. This is considered a
syntax rule, since it is relevant to overload resolution. We
choose not to express it with BNF so we can share the definition
of record_component_association_list in both record_aggregate and
extension_aggregate.
7.b Ramification: The record_component_association_list of an
extension_aggregate does not have such a restriction.
Name Resolution Rules
8/2 {AI95-00287-01} The expected type for a record_aggregate shall be a single
record type or record extension.
8.a Ramification: This rule is used to resolve whether an aggregate is
an array_aggregate or a record_aggregate. The presence of a with
is used to resolve between a record_aggregate and an
extension_aggregate.
9 For the record_component_association_list of a record_aggregate, all
components of the composite value defined by the aggregate are needed[; for
the association list of an extension_aggregate, only those components not
determined by the ancestor expression or subtype are needed (see 4.3.2).] Each
selector_name in a record_component_association shall denote a needed
component [(including possibly a discriminant)].
9.a Ramification: For the association list of a record_aggregate, "
needed components" includes every component of the composite
value, but does not include those in unchosen variants (see
AI83-309). If there are variants, then the value specified for the
discriminant that governs them determines which variant is chosen,
and hence which components are needed.
9.b If an extension defines a new known_discriminant_part, then all of
its discriminants are needed in the component association list of
an extension aggregate for that type, even if the discriminants
have the same names and types as discriminants of the type of the
ancestor expression. This is necessary to ensure that the
positions in the record_component_association_list are well
defined, and that discriminants that govern variant_parts can be
given by static expressions.
10 The expected type for the expression of a record_component_association is
the type of the associated component(s); the associated component(s) are as
follows:
11 * For a positional association, the component [(including possibly a
discriminant)] in the corresponding relative position (in the
declarative region of the type), counting only the needed components;
11.a Ramification: This means that for an association list of an
extension_aggregate, only noninherited components are counted to
determine the position.
11.b/3 {AI05-0005-1} For a derived type (including type extensions), the
order of declaration is defined in 3.4, "
Derived Types and Classes". In particular, all discriminants come
first, regardless of whether they are defined for the parent type
or are newly added to the derived type.
12 * For a named association with one or more component_selector_names, the
named component(s);
13 * For a named association with the reserved word others, all needed
components that are not associated with some previous association.
Legality Rules
14 If the type of a record_aggregate is a record extension, then it shall be
a descendant of a record type, through one or more record extensions (and no
private extensions).
15/3 {AI05-0016-1} The reserved words null record may appear only if there are
no components needed in a given record_component_association_list.
15.a Ramification: For example, "(null record)" is a record_aggregate
for a null record type. Similarly, "(T'(A) with null record)" is
an extension_aggregate for a type defined as a null record
extension of T.
15.b/3 {AI05-0016-1} If no components are needed and null record is not
used, the record_component_association must necessarily be others
=> <>, as that is the only record_component_association that does
not require an associated component.
16/4 {AI95-00287-01} {AI05-0199-1} {AI12-0046-1} Each
record_component_association other than an others choice with a <> shall have
at least one associated component, and each needed component shall be
associated with exactly one record_component_association. If a
record_component_association with an expression has two or more associated
components, all of them shall be of the same type, or all of them shall be of
anonymous access types whose subtypes statically match. In addition,
Legality Rules are enforced separately for each associated component.
16.a/2 Ramification: {AI95-00287-01} These rules apply to an association
with an others choice with an expression. An others choice with a
<> can match zero components or several components with different
types.
16.b/2 Reason: {AI95-00287-01} Without these rules, there would be no way
to know what was the expected type for the expression of the
association. Note that some of the rules do not apply to <>
associations, as we do not need to resolve anything. We allow
others => <> to match no components as this is similar to array
aggregates. That means that (others => <>) always represents a
default-initialized record or array value.
16.c/4 Discussion: {AI12-0046-1} AI83-00244 also requires that the
expression shall be legal for each associated component. Ada 95
omitted this wording, as it was thought that all cases of
difference had been eliminated. That probably was true, but Ada
2005 reintroduced cases where the types match but the legality
differs. For example:
16.c.1/4 type Rec (D : access Integer) is record
F : access Integer;
end record;
16.c.2/4 ...
X : aliased Integer;
R : Rec := (D | F => X'Access); -- Legal for D, illegal for F
16.c.3/4 There are additional ways for this to happen; because of cases
like the above we require that the Legality Rules are checked
individually for each associated component.
16.d Ramification: The rule that requires at least one associated
component for each record_component_association implies that there
can be no extra associations for components that don't exist in
the composite value, or that are already determined by the
ancestor expression or subtype of an extension_aggregate.
16.e The second part of the first sentence ensures that no needed
components are left out, nor specified twice.
17/3 {AI05-0220-1} The value of a discriminant that governs a variant_part P
shall be given by a static expression, unless P is nested within a variant V
that is not selected by the discriminant value governing the variant_part
enclosing V.
17.a Ramification: This expression might either be given within the
aggregate itself, or in a constraint on the parent subtype in a
derived_type_definition for some ancestor of the type of the
aggregate.
17.1/2 {AI95-00287-01} A record_component_association for a discriminant
without a default_expression shall have an expression rather than <>.
17.b/2 Reason: A discriminant must always have a defined value, but <>
means uninitialized for a discrete type unless the component has a
default value.
Dynamic Semantics
18 The evaluation of a record_aggregate consists of the evaluation of the
record_component_association_list.
19 For the evaluation of a record_component_association_list, any per-object
constraints (see 3.8) for components specified in the association list are
elaborated and any expressions are evaluated and converted to the subtype of
the associated component. Any constraint elaborations and expression
evaluations (and conversions) occur in an arbitrary order, except that the
expression for a discriminant is evaluated (and converted) prior to the
elaboration of any per-object constraint that depends on it, which in turn
occurs prior to the evaluation and conversion of the expression for the
component with the per-object constraint.
19.a Ramification: The conversion in the first rule might raise
Constraint_Error.
19.b Discussion: This check in the first rule presumably happened as
part of the dependent compatibility check in Ada 83.
19.1/2 {AI95-00287-01} For a record_component_association with an expression,
the expression defines the value for the associated component(s). For a
record_component_association with <>, if the component_declaration has a
default_expression, that default_expression defines the value for the
associated component(s); otherwise, the associated component(s) are
initialized by default as for a stand-alone object of the component subtype
(see 3.3.1).
20 The expression of a record_component_association is evaluated (and
converted) once for each associated component.
20.a/3 Ramification: {AI05-0005-1} We don't need similar language for <>,
as we're considering the value of <> for each individual
component. Each component has its own default expression or its
own default initialization (they can be different for each
component; the components even could have different types), and
each one has to be evaluated. So there is no need to repeat that.
NOTES
21 8 For a record_aggregate with positional associations, expressions
specifying discriminant values appear first since the
known_discriminant_part is given first in the declaration of the type;
they have to be in the same order as in the known_discriminant_part.
Examples
22 Example of a record aggregate with positional associations:
23 (4, July, 1776) -- see 3.8
24 Examples of record aggregates with named associations:
25 (Day => 4, Month => July, Year => 1776)
(Month => July, Day => 4, Year => 1776)
26 (Disk, Closed, Track => 5, Cylinder => 12) -- see 3.8.1
(Unit => Disk, Status => Closed, Cylinder => 9, Track => 1)
27/2 {AI95-00287-01} Examples of component associations with several choices:
28 (Value => 0, Succ|Pred => new Cell'(0, null, null))
-- see 3.10.1
29 -- The allocator is evaluated twice: Succ and Pred designate different cells
29.1/2 (Value => 0, Succ|Pred => <>)
-- see 3.10.1
29.2/2 -- Succ and Pred will be set to null
30 Examples of record aggregates for tagged types (see 3.9 and 3.9.1):
31 Expression'(null record)
Literal'(Value => 0.0)
Painted_Point'(0.0, Pi/2.0, Paint => Red)
Extensions to Ada 83
31.a Null record aggregates may now be specified, via "(null record)".
However, this syntax is more useful for null record extensions in
extension aggregates.
Wording Changes from Ada 83
31.b Various AIs have been incorporated (AI83-00189, AI83-00244, and
AI83-00309). In particular, Ada 83 did not explicitly disallow
extra values in a record aggregate. Now we do.
Extensions to Ada 95
31.c/2 {AI95-00287-01} <> can be used in place of an expression in a
record_aggregate, default initializing the component.
Wording Changes from Ada 95
31.d/2 {AI95-00287-01} Limited record_aggregates are allowed (since all
kinds of aggregates can now be limited, see 4.3).
Incompatibilities With Ada 2005
31.e/3 {AI05-0220-1} Correction: Corrected wording so that the rule for
discriminants governing variant_parts was not effectively
circular. The change makes a few aggregates where a nonstatic
discriminant governs an empty variant_part illegal. However, most
Ada implementations already enforce some version of the new rule
and already reject these aggregates. So it is unlikely that any
incompatibility will be noticed in practice.
Extensions to Ada 2005
31.f/3 {AI05-0016-1} Correction: Fixed the wording so that others => <>
can be used in place of null record. This is needed to avoid a
generic contract issue for generic bodies: we do not want to have
to assume the worst to disallow others => <> if the record type
might be a null record.
31.g/3 {AI05-0199-1} Correction: We now allow multiple components with
anonymous access types to be specified with a single component
association. This is to be consistent with the capabilities of a
named access type.
Wording Changes from Ada 2012
31.h/4 {AI12-0046-1} Corrigendum: We explicitly say that the
Legality Rules have to be rechecked for each component
individually. This seems obvious, but as the AARM note 4.3.1
(16.c) appeared to say that this was not necessary, and since we
explicitly state this sort of thing for generic instances, it
seemed better to be explicit.
4.3.2 Extension Aggregates
1 [An extension_aggregate specifies a value for a type that is a record
extension by specifying a value or subtype for an ancestor of the type,
followed by associations for any components not determined by the
ancestor_part.]
Language Design Principles
1.a The model underlying this syntax is that a record extension can
also be viewed as a regular record type with an ancestor "prefix."
The record_component_association_list corresponds to exactly what
would be needed if there were no ancestor/prefix type. The
ancestor_part determines the value of the ancestor/prefix.
Syntax
2 extension_aggregate ::=
(ancestor_part with record_component_association_list)
3 ancestor_part ::= expression | subtype_mark
Name Resolution Rules
4/2 {AI95-00287-01} The expected type for an extension_aggregate shall be a
single type that is a record extension. If the ancestor_part is an
expression, it is expected to be of any tagged type.
4.a Reason: We could have made the expected type T'Class where T is
the ultimate ancestor of the type of the aggregate, or we could
have made it even more specific than that. However, if the
overload resolution rules get too complicated, the implementation
gets more difficult and it becomes harder to produce good error
messages.
4.b/3 Ramification: {AI05-0005-1} This rule is additive with the rule
given in 4.3. That means the 4.3 rule must be satisfied even
though it is always syntactically possible to tell that something
is an extension aggregate rather than another kind of aggregate.
Specifically, that means that an extension aggregate is ambiguous
if the context is overloaded on array and/or untagged record
types, even though those are never legal contexts for an extension
aggregate. Thus, this rule acts more like a Legality Rule than a
Name Resolution Rule.
Legality Rules
5/3 {AI95-00306-01} {AI05-0115-1} If the ancestor_part is a subtype_mark, it
shall denote a specific tagged subtype. If the ancestor_part is an
expression, it shall not be dynamically tagged. The type of the
extension_aggregate shall be a descendant of the type of the ancestor_part
(the ancestor type), through one or more record extensions (and no private
extensions). If the ancestor_part is a subtype_mark, the view of the ancestor
type from which the type is descended (see 7.3.1) shall not have unknown
discriminants.
5.a/2 Reason: {AI95-00306-01} The expression cannot be dynamically
tagged to prevent implicit "truncation" of a dynamically-tagged
value to the specific ancestor type. This is similar to the rules
in 3.9.2.
5.1/3 {AI05-0067-1} {AI05-0244-1} If the type of the ancestor_part is limited
and at least one component is needed in the
record_component_association_list, then the ancestor_part shall not be:
5.2/3 * a call to a function with an unconstrained result subtype; nor
5.3/3 * a parenthesized or qualified expression whose operand would violate
this rule; nor
5.4/3 * a conditional_expression having at least one dependent_expression
that would violate this rule.
5.b/3 Reason: {AI05-0067-1} {AI05-0244-1} This restriction simplifies
implementation, because it ensures that either the caller or the
callee knows the size to allocate for the aggregate. Without this
restriction, information from both caller and callee would have to
be combined to determine the appropriate size.
5.c/3 {AI05-0067-1} The (F(...) with null record) case is exempt from
this rule, because such extension aggregates are created
internally for inherited functions returning null-extension types
- we can't very well make those illegal. Moreover, we don't need
the rule for null extensions, as the result can simply use the
space returned by the function call.
Static Semantics
6 For the record_component_association_list of an extension_aggregate, the
only components needed are those of the composite value defined by the
aggregate that are not inherited from the type of the ancestor_part, plus any
inherited discriminants if the ancestor_part is a subtype_mark that denotes an
unconstrained subtype.
Dynamic Semantics
7 For the evaluation of an extension_aggregate, the record_component_-
association_list is evaluated. If the ancestor_part is an expression, it is
also evaluated; if the ancestor_part is a subtype_mark, the components of the
value of the aggregate not given by the record_component_association_list are
initialized by default as for an object of the ancestor type. Any implicit
initializations or evaluations are performed in an arbitrary order, except
that the expression for a discriminant is evaluated prior to any other
evaluation or initialization that depends on it.
8/3 {AI05-0282-1} If the type of the ancestor_part has discriminants and the
ancestor_part is not a subtype_mark that denotes an unconstrained subtype,
then a check is made that each discriminant determined by the ancestor_part
has the value specified for a corresponding discriminant, if any, either in
the record_component_association_list, or in the derived_type_definition for
some ancestor of the type of the extension_aggregate. Constraint_Error is
raised if this check fails.
8.a Ramification: Corresponding and specified discriminants are
defined in 3.7. The rules requiring static compatibility between
new discriminants of a derived type and the parent discriminant(s)
they constrain ensure that at most one check is required per
discriminant of the ancestor expression.
8.b/3 {AI05-0282-1} The check needs to be made any time that the
ancestor is constrained; the source of the discriminants or the
constraints is irrelevant.
NOTES
9 9 If all components of the value of the extension_aggregate are
determined by the ancestor_part, then the record_component_association_-
list is required to be simply null record.
10 10 If the ancestor_part is a subtype_mark, then its type can be
abstract. If its type is controlled, then as the last step of
evaluating the aggregate, the Initialize procedure of the ancestor
type is called, unless the Initialize procedure is abstract (see 7.6
).
Examples
11 Examples of extension aggregates (for types defined in 3.9.1):
12 Painted_Point'(Point with Red)
(Point'(P) with Paint => Black)
13 (Expression with Left => 1.2, Right => 3.4)
Addition'(Binop with null record)
-- presuming Binop is of type Binary_Operation
Extensions to Ada 83
13.a The extension aggregate syntax is new.
Incompatibilities With Ada 95
13.b/2 {AI95-00306-01} Amendment Correction: Eliminated implicit "
truncation" of a dynamically tagged value when it is used as an
ancestor expression. If an aggregate includes such an expression,
it is illegal in Ada 2005. Such aggregates are thought to be rare;
the problem can be fixed with a type conversion to the appropriate
specific type if it occurs.
Wording Changes from Ada 95
13.c/2 {AI95-00287-01} Limited extension_aggregates are allowed (since
all kinds of aggregates can now be limited, see 4.3).
Inconsistencies With Ada 2005
13.d/3 {AI05-0282-1} Correction: An extension_aggregate with an
ancestor_part whose discriminants are constrained and inherited
might now raise Constraint_Error if the aggregate's type is
constrained, while it was OK in Ada 2005. In almost all cases,
this will make no difference as the constraint will be checked by
the immediately following use of the aggregate, but it is possible
to compare such an aggregate for equality; in this case, no
exception would be raised by Ada 2005, while Ada 2012 will raise
Constraint_Error. This should be very rare, and having the
possibility means that the representation of the aggregate type
has to be able to support unconstrained values of the type, even
if the first subtype is constrained and no such objects can be
created any other way.
Incompatibilities With Ada 2005
13.e/3 {AI05-0067-1} Correction: A limited unconstrained ancestor
expression that is a function call is now illegal unless the
extension part is null. Such aggregates were first introduced in
Ada 2005 and are very complex to implement as they must be
built-in-place with an unknown size; as such, it is unlikely that
they are implemented correctly in existing compilers and thus not
often used in existing code.
13.f/3 {AI05-0115-1} Correction: An ancestor_part that is a subtype with
unknown discriminants is now explicitly illegal. Such a subtype
should not be used to declare an object, and the ancestor_part
acts like an object. The Ada 95 rules did not disallow such cases,
so it is possible that code exists that uses such an ancestor, but
this should be rare.
4.3.3 Array Aggregates
1 [In an array_aggregate, a value is specified for each component of an
array, either positionally or by its index.] For a
positional_array_aggregate, the components are given in increasing-index
order, with a final others, if any, representing any remaining components. For
a named_array_aggregate, the components are identified by the values covered
by the discrete_choices.
Language Design Principles
1.a/1 The rules in this subclause are based on terms and rules for
discrete_choice_lists defined in 3.8.1, "
Variant Parts and Discrete Choices". For example, the requirements
that others come last and stand alone are found there.
Syntax
2 array_aggregate ::=
positional_array_aggregate | named_array_aggregate
3/2 {AI95-00287-01} positional_array_aggregate ::=
(expression, expression {, expression})
| (expression {, expression}, others => expression)
| (expression {, expression}, others => <>)
4 named_array_aggregate ::=
(array_component_association {, array_component_association})
5/2 {AI95-00287-01} array_component_association ::=
discrete_choice_list => expression
| discrete_choice_list => <>
6 An n-dimensional array_aggregate is one that is written as n levels of
nested array_aggregates (or at the bottom level, equivalent string_literals).
For the multidimensional case (n >= 2) the array_aggregates (or equivalent
string_literals) at the n-1 lower levels are called subaggregates of the
enclosing n-dimensional array_aggregate. The expressions of the bottom level
subaggregates (or of the array_aggregate itself if one-dimensional) are called
the array component expressions of the enclosing n-dimensional
array_aggregate.
6.a Ramification: Subaggregates do not have a type. They correspond to
part of an array. For example, with a matrix, a subaggregate would
correspond to a single row of the matrix. The definition of
"n-dimensional" array_aggregate applies to subaggregates as well
as aggregates that have a type.
6.b To be honest: An others choice is the reserved word others as it
appears in a positional_array_aggregate or as the
discrete_choice of the discrete_choice_list in an
array_component_association.
Name Resolution Rules
7/2 {AI95-00287-01} The expected type for an array_aggregate (that is not a
subaggregate) shall be a single array type. The component type of this array
type is the expected type for each array component expression of the
array_aggregate.
7.a/2 Ramification: {AI95-00287-01} We already require a single array or
record type or record extension for an aggregate. The above rule
requiring a single array type (and similar ones for record and
extension aggregates) resolves which kind of aggregate you have.
8 The expected type for each discrete_choice in any discrete_choice_list of
a named_array_aggregate is the type of the corresponding index; the
corresponding index for an array_aggregate that is not a subaggregate is the
first index of its type; for an (n-m)-dimensional subaggregate within an
array_aggregate of an n-dimensional type, the corresponding index is the index
in position m+1.
Legality Rules
9 An array_aggregate of an n-dimensional array type shall be written as an
n-dimensional array_aggregate.
9.a Ramification: In an m-dimensional array_aggregate [(including a
subaggregate)], where m >= 2, each of the expressions has to be an
(m-1)-dimensional subaggregate.
10 An others choice is allowed for an array_aggregate only if an applicable
index constraint applies to the array_aggregate. [An applicable index
constraint is a constraint provided by certain contexts where an
array_aggregate is permitted that can be used to determine the bounds of the
array value specified by the aggregate.] Each of the following contexts (and
none other) defines an applicable index constraint:
11/4 * {AI95-00318-02} {AI12-0157-1} For an explicit_actual_parameter, an
explicit_generic_actual_parameter, the expression of a return
statement, the return expression of an expression function, the
initialization expression in an object_declaration, or a default_-
expression [(for a parameter or a component)], when the nominal
subtype of the corresponding formal parameter, generic formal
parameter, function return object, expression function return object,
object, or component is a constrained array subtype, the applicable
index constraint is the constraint of the subtype;
12 * For the expression of an assignment_statement where the name denotes
an array variable, the applicable index constraint is the constraint
of the array variable;
12.a Reason: This case is broken out because the constraint comes from
the actual subtype of the variable (which is always constrained)
rather than its nominal subtype (which might be unconstrained).
13 * For the operand of a qualified_expression whose subtype_mark denotes a
constrained array subtype, the applicable index constraint is the
constraint of the subtype;
14 * For a component expression in an aggregate, if the component's nominal
subtype is a constrained array subtype, the applicable index
constraint is the constraint of the subtype;
14.a Discussion: Here, the array_aggregate with others is being used
within a larger aggregate.
15/3 * {AI05-0147-1} For a parenthesized expression, the applicable index
constraint is that, if any, defined for the expression;
15.a Discussion: RM83 omitted this case, presumably as an oversight. We
want to minimize situations where an expression becomes illegal if
parenthesized.
15.1/3 * {AI05-0147-1} For a conditional_expression, the applicable index
constraint for each dependent_expression is that, if any, defined for
the conditional_expression.
16 The applicable index constraint applies to an array_aggregate that appears
in such a context, as well as to any subaggregates thereof. In the case of an
explicit_actual_parameter (or default_expression) for a call on a generic
formal subprogram, no applicable index constraint is defined.
16.a Reason: This avoids generic contract model problems, because only
mode conformance is required when matching actual subprograms with
generic formal subprograms.
17/3 {AI05-0153-3} The discrete_choice_list of an
array_component_association is allowed to have a discrete_choice that is a
nonstatic choice_expression or that is a subtype_indication or range that
defines a nonstatic or null range, only if it is the single discrete_choice of
its discrete_choice_list, and there is only one array_component_association in
the array_aggregate.
17.a Discussion: We now allow a nonstatic others choice even if there
are other array component expressions as well.
18/3 {AI05-0262-1} In a named_array_aggregate where all discrete_choices are
static, no two discrete_choices are allowed to cover the same value (see
3.8.1); if there is no others choice, the discrete_choices taken together
shall exactly cover a contiguous sequence of values of the corresponding index
type.
18.a Ramification: This implies that each component must be specified
exactly once. See AI83-309.
18.b/3 Reason: {AI05-0262-1} This has to apply even if there is only one
static discrete_choice; a single choice has to represent a
contiguous range (a subtype_mark with a static predicate might
represent a discontiguous set of values). If the (single) choice
is a dynamic subtype, we don't need to make this check as no
predicates are allowed (see 3.2.4) and thus the range has to be
contiguous.
19 A bottom level subaggregate of a multidimensional array_aggregate of a
given array type is allowed to be a string_literal only if the component type
of the array type is a character type; each character of such a
string_literal shall correspond to a defining_character_literal of the
component type.
Static Semantics
20 A subaggregate that is a string_literal is equivalent to one that is a
positional_array_aggregate of the same length, with each expression being the
character_literal for the corresponding character of the string_literal.
Dynamic Semantics
21 The evaluation of an array_aggregate of a given array type proceeds in two
steps:
22 1. Any discrete_choices of this aggregate and of its subaggregates are
evaluated in an arbitrary order, and converted to the corresponding
index type;
23 2. The array component expressions of the aggregate are evaluated in an
arbitrary order and their values are converted to the component
subtype of the array type; an array component expression is evaluated
once for each associated component.
23.a Ramification: Subaggregates are not separately evaluated. The
conversion of the value of the component expressions to the
component subtype might raise Constraint_Error.
23.b/3 {AI05-0005-1} We don't need to say that <> is evaluated once for
each component, as <> means that each component is initialized by
default. That means that the actions defined for default
initialization are applied to each component individually.
Initializing one component by default and copying that to the
others would be an incorrect implementation in general (although
it might be OK if the default initialization is known to be
constant).
23.1/4 {AI95-00287-01} {AI12-0084-1} Each expression in an
array_component_association defines the value for the associated component(s).
For an array_component_association with <>, the associated component(s) are
initialized to the Default_Component_Value of the array type if this aspect
has been specified for the array type; otherwise, they are initialized by
default as for a stand-alone object of the component subtype (see 3.3.1).
24 The bounds of the index range of an array_aggregate [(including a
subaggregate)] are determined as follows:
25 * For an array_aggregate with an others choice, the bounds are those of
the corresponding index range from the applicable index constraint;
26 * For a positional_array_aggregate [(or equivalent string_literal)]
without an others choice, the lower bound is that of the corresponding
index range in the applicable index constraint, if defined, or that of
the corresponding index subtype, if not; in either case, the upper
bound is determined from the lower bound and the number of
expressions [(or the length of the string_literal)];
27 * For a named_array_aggregate without an others choice, the bounds are
determined by the smallest and largest index values covered by any
discrete_choice_list.
27.a Reason: We don't need to say that each index value has to be
covered exactly once, since that is a ramification of the general
rule on aggregates that each component's value has to be specified
exactly once.
28 For an array_aggregate, a check is made that the index range defined by
its bounds is compatible with the corresponding index subtype.
28.a Discussion: In RM83, this was phrased more explicitly, but once we
define "compatibility" between a range and a subtype, it seems to
make sense to take advantage of that definition.
28.b Ramification: The definition of compatibility handles the special
case of a null range, which is always compatible with a subtype.
See AI83-00313.
29/3 {AI05-0037-1} For an array_aggregate with an others choice, a check is
made that no expression or <> is specified for an index value outside the
bounds determined by the applicable index constraint.
29.a Discussion: RM83 omitted this case, apparently through an
oversight. AI83-00309 defines this as a dynamic check, even though
other Ada 83 rules ensured that this check could be performed
statically. We now allow an others choice to be dynamic, even if
it is not the only choice, so this check now needs to be dynamic,
in some cases. Also, within a generic unit, this would be a
nonstatic check in some cases.
30 For a multidimensional array_aggregate, a check is made that all
subaggregates that correspond to the same index have the same bounds.
30.a Ramification: No array bounds "sliding" is performed on
subaggregates.
30.b Reason: If sliding were performed, it would not be obvious which
subaggregate would determine the bounds of the corresponding
index.
31 The exception Constraint_Error is raised if any of the above checks fail.
NOTES
32/3 11 {AI05-0004-1} In an array_aggregate, positional notation may only
be used with two or more expressions; a single expression in
parentheses is interpreted as a parenthesized expression. A
named_array_aggregate, such as (1 => X), may be used to specify an
array with a single component.
Examples
33 Examples of array aggregates with positional associations:
34 (7, 9, 5, 1, 3, 2, 4, 8, 6, 0)
Table'(5, 8, 4, 1, others => 0) -- see 3.6
35 Examples of array aggregates with named associations:
36 (1 .. 5 => (1 .. 8 => 0.0)) -- two-dimensional
(1 .. N => new Cell) -- N new cells, in particular for N = 0
37 Table'(2 | 4 | 10 => 1, others => 0)
Schedule'(Mon .. Fri => True, others => False) -- see 3.6
Schedule'(Wed | Sun => False, others => True)
Vector'(1 => 2.5) -- single-component vector
38 Examples of two-dimensional array aggregates:
39 -- Three aggregates for the same value of subtype Matrix(1..2,1..3) (see 3.6
):
40 ((1.1, 1.2, 1.3), (2.1, 2.2, 2.3))
(1 => (1.1, 1.2, 1.3), 2 => (2.1, 2.2, 2.3))
(1 => (1 => 1.1, 2 => 1.2, 3 => 1.3), 2 => (1 => 2.1, 2 => 2.2, 3 => 2.3))
41 Examples of aggregates as initial values:
42 A : Table := (7, 9, 5, 1, 3, 2, 4, 8, 6, 0); -- A(1)=7, A(10)=0
B : Table := (2 | 4 | 10 => 1, others => 0); -- B(1)=0, B(10)=1
C : constant Matrix := (1 .. 5 => (1 .. 8 => 0.0)); -- C'Last(1)=5, C'Last(2)=8
43 D : Bit_Vector(M .. N) := (M .. N => True); -- see 3.6
E : Bit_Vector(M .. N) := (others => True);
F : String(1 .. 1) := (1 => 'F'); -- a one component aggregate: same as "F"
44/2 {AI95-00433-01} Example of an array aggregate with defaulted others
choice and with an applicable index constraint provided by an enclosing record
aggregate:
45/2 Buffer'(Size => 50, Pos => 1, Value => String'('x', others => <>)) -- see 3.7
Incompatibilities With Ada 83
45.a.1/1 In Ada 95, no applicable index constraint is defined for a
parameter in a call to a generic formal subprogram; thus, some
aggregates that are legal in Ada 83 are illegal in Ada 95. For
example:
45.a.2/1 subtype S3 is String (1 .. 3);
...
generic
with function F (The_S3 : in S3) return Integer;
package Gp is
I : constant Integer := F ((1 => '!', others => '?'));
-- The aggregate is legal in Ada 83, illegal in Ada 95.
end Gp;
45.a.3/1 This change eliminates generic contract model problems.
Extensions to Ada 83
45.a We now allow "named with others" aggregates in all contexts where
there is an applicable index constraint, effectively eliminating
what was RM83-4.3.2(6). Sliding never occurs on an aggregate with
others, because its bounds come from the applicable index
constraint, and therefore already match the bounds of the target.
45.b The legality of an others choice is no longer affected by the
staticness of the applicable index constraint. This substantially
simplifies several rules, while being slightly more flexible for
the user. It obviates the rulings of AI83-00244 and AI83-00310,
while taking advantage of the dynamic nature of the "extra values"
check required by AI83-00309.
45.c Named array aggregates are permitted even if the index type is
descended from a formal scalar type. See 4.9 and AI83-00190.
Wording Changes from Ada 83
45.d We now separate named and positional array aggregate syntax,
since, unlike other aggregates, named and positional associations
cannot be mixed in array aggregates (except that an others choice
is allowed in a positional array aggregate).
45.e We have also reorganized the presentation to handle
multidimensional and one-dimensional aggregates more uniformly,
and to incorporate the rulings of AI83-00019, AI83-00309, etc.
Extensions to Ada 95
45.f/2 {AI95-00287-01} <> can be used in place of an expression in an
array_aggregate, default-initializing the component.
Wording Changes from Ada 95
45.g/2 {AI95-00287-01} Limited array_aggregates are allowed (since all
kinds of aggregates can now be limited, see 4.3).
45.h/2 {AI95-00318-02} Fixed aggregates to use the subtype of the return
object of a function, rather than the result subtype, because they
can be different for an extended_return_statement, and we want to
use the subtype that's explicitly in the code at the point of the
expression.
Inconsistencies With Ada 2005
45.i/3 {AI05-0037-1} Correction: Fixed so the check for components
outside of the array applies to both expressions and <>s. As <>
was a new feature in Ada 2005, there should be little existing
code that depends on a <> component that is specified outside of
the array (and that is nonsense anyway, that a compiler is likely
to detect even without an explicit language rule disallowing it).
Wording Changes from Ada 2005
45.j/3 {AI05-0147-1} Added a definition of the applicable index
constraint for conditional_expressions (which are new).
Inconsistencies With Ada 2012
45.k/4 {AI05-0084-1} Corrigendum: Fixed so that the
Default_Component_Value (if any) is used to initialize components
specified with <>. This is what users would expect, and all Ada
2012 implementation known at the time of this writing initialize
with the Default_Component_Value, so it is unlikely that anyone
will be affected by this inconsistency.
Wording Changes from Ada 2012
45.l/4 {AI05-0157-1} Corrigendum: Added expression functions to the
contexts that provide an applicable index constraint, because
expression functions are handled separately in static semantics
and legality rules.
4.4 Expressions
1/3 {AI05-0147-1} {AI05-0158-1} {AI05-0176-1} An expression is a formula that
defines the computation or retrieval of a value. In this International
Standard, the term "expression" refers to a construct of the syntactic
category expression or of any of the following categories: choice_expression,
choice_relation, relation, simple_expression, term, factor, primary,
conditional_expression, quantified_expression.
Syntax
2 expression ::=
relation {and relation} | relation {and then relation}
| relation {or relation} | relation {or else relation}
| relation {xor relation}
2.1/3 {AI05-0158-1} choice_expression ::=
choice_relation {and choice_relation}
| choice_relation {or choice_relation}
| choice_relation {xor choice_relation}
| choice_relation {and then choice_relation}
| choice_relation {or else choice_relation}
2.2/3 {AI05-0158-1} choice_relation ::=
simple_expression [relational_operator simple_expression]
3/4 {AI05-0158-1} {AI12-0022-1} {AI12-0039-1} relation ::=
simple_expression [relational_operator simple_expression]
| tested_simple_expression [not] in membership_choice_list
| raise_expression
3.1/3 {AI05-0158-1} membership_choice_list ::= membership_choice
{| membership_choice}
3.2/4 {AI05-0158-1} {AI12-0039-1} membership_choice ::=
choice_simple_expression | range | subtype_mark
4 simple_expression ::= [unary_adding_operator] term
{binary_adding_operator term}
5 term ::= factor {multiplying_operator factor}
6 factor ::= primary [** primary] | abs primary | not primary
7/3 {AI05-0003-1} {AI05-0147-1} {AI05-0176-1} primary ::=
numeric_literal | null | string_literal | aggregate
| name | allocator | (expression)
| (conditional_expression) | (quantified_expression)
Name Resolution Rules
8 A name used as a primary shall resolve to denote an object or a value.
8.a Discussion: This replaces RM83-4.4(3). We don't need to mention
named numbers explicitly, because the name of a named number
denotes a value. We don't need to mention attributes explicitly,
because attributes now denote (rather than yield) values in
general. Also, the new wording allows attributes that denote
objects, which should always have been allowed (in case the
implementation chose to have such a thing).
8.b Reason: It might seem odd that this is an overload resolution
rule, but it is relevant during overload resolution. For example,
it helps ensure that a primary that consists of only the
identifier of a parameterless function is interpreted as a
function_call rather than directly as a direct_name.
Static Semantics
9 Each expression has a type; it specifies the computation or retrieval of a
value of that type.
Dynamic Semantics
10 The value of a primary that is a name denoting an object is the value of
the object.
Implementation Permissions
11 For the evaluation of a primary that is a name denoting an object of an
unconstrained numeric subtype, if the value of the object is outside the base
range of its type, the implementation may either raise Constraint_Error or
return the value of the object.
11.a/3 Ramification: {AI05-0299-1} This means that if extra-range
intermediates are used to hold the value of an object of an
unconstrained numeric subtype, a Constraint_Error can be raised on
a read of the object, rather than only on an assignment to it.
Similarly, it means that computing the value of an object of such
a subtype can be deferred until the first read of the object
(presuming no side effects other than failing an Overflow_Check
are possible). This permission is over and above that provided by
subclause 11.6, since this allows the Constraint_Error to move to
a different handler.
11.b Reason: This permission is intended to allow extra-range registers
to be used efficiently to hold parameters and local variables,
even if they might need to be transferred into smaller registers
for performing certain predefined operations.
11.c Discussion: There is no need to mention other kinds of primarys,
since any Constraint_Error to be raised can be "charged" to the
evaluation of the particular kind of primary.
Examples
12 Examples of primaries:
13 4.0 -- real literal
Pi -- named number
(1 .. 10 => 0) -- array aggregate
Sum -- variable
Integer'Last -- attribute
Sine(X) -- function call
Color'(Blue) -- qualified expression
Real(M*N) -- conversion
(Line_Count + 10) -- parenthesized expression
14 Examples of expressions:
15/2 {AI95-00433-01} Volume -- primary
not Destroyed -- factor
2*Line_Count -- term
-4.0 -- simple expression
-4.0 + A -- simple expression
B**2 - 4.0*A*C -- simple expression
R*Sin(<Unicode-952>)*Cos(<Unicode-966>
) -- simple expression
Password(1 .. 3) = "Bwv" -- relation
Count in Small_Int -- relation
Count not in Small_Int -- relation
Index = 0 or Item_Hit -- expression
(Cold and Sunny) or Warm -- expression (parentheses are required)
A**(B**C) -- expression (parentheses are required)
Extensions to Ada 83
15.a In Ada 83, out parameters and their nondiscriminant subcomponents
are not allowed as primaries. These restrictions are eliminated in
Ada 95.
15.b In various contexts throughout the language where Ada 83 syntax
rules had simple_expression, the corresponding Ada 95 syntax rule
has expression instead. This reflects the inclusion of modular
integer types, which makes the logical operators "and", "or", and
"xor" more useful in expressions of an integer type. Requiring
parentheses to use these operators in such contexts seemed
unnecessary and potentially confusing. Note that the bounds of a
range still have to be specified by simple_expressions, since
otherwise expressions involving membership tests might be
ambiguous. Essentially, the operation ".." is of higher precedence
than the logical operators, and hence uses of logical operators
still have to be parenthesized when used in a bound of a range.
Wording Changes from Ada 2005
15.c/3 {AI05-0003-1} Moved qualified_expression from primary to name (see
4.1). This allows the use of qualified_expressions in more places.
15.d/3 {AI05-0147-1} {AI05-0176-1} Added conditional_expression and
quantified_expression to primary.
15.e/3 {AI05-0158-1} Expanded membership test syntax (see 4.5.2).
Inconsistencies With Ada 2012
15.f/4 {AI12-0039-1} Corrigendum: Revised membership syntax to eliminate
ambiguities. In some cases, previously ambiguous membership
expressions will now have an unambiguous meaning. If an Ada 2012
implementation chose the "wrong" meaning, the expression could
silently change meaning. Virtually all such expressions will
become illegal because of type mismatches (and thus be
incompatible, not inconsistent). However, if the choices are all
of a Boolean type, resolution might succeed. For instance, A in B
| C and D now always means (A in B | C) and D, but the original
Ada 2012 syntax would have allowed it to mean A in B | (C and D).
If a compiler allowed the expression and interpreted it as the
latter, the meaning of the expression would silently change. We
expect this to be extremely rare as membership operations on
Boolean types are unlikely (and this can happen only in code
written for Ada 2012).
Incompatibilities With Ada 2012
15.g/4 {AI12-0039-1} Corrigendum: The revised membership syntax will
require parentheses in membership_choice_lists in some cases where
the Ada 2012 grammar did not require them. For instance, A in B in
C | D is now illegal. However, such expressions can be interpreted
in multiple ways (either A in (B in C) | D or A in (B in C | D)
for this example), so using such expressions is likely to be
dangerous (another compiler might interpret the expression
differently). In addition, all such expressions occur only in Ada
2012 syntax; so they should be rare.
4.5 Operators and Expression Evaluation
1 [ The language defines the following six categories of operators (given in
order of increasing precedence). The corresponding operator_symbols, and only
those, can be used as designators in declarations of functions for
user-defined operators. See 6.6, "Overloading of Operators".]
Syntax
2 logical_operator ::= and | or | xor
3 relational_operator ::=
= | /= | < | <= | > | >=
4 binary_adding_operator ::= + | - | &
5 unary_adding_operator ::= + | -
6 multiplying_operator ::= * | / | mod | rem
7 highest_precedence_operator ::= ** | abs | not
7.a Discussion: Some of the above syntactic categories are not used in
other syntax rules. They are just used for classification. The
others are used for both classification and parsing.
Static Semantics
8 For a sequence of operators of the same precedence level, the operators
are associated with their operands in textual order from left to right.
Parentheses can be used to impose specific associations.
8.a Discussion: The left-associativity is not directly inherent in the
grammar of 4.4, though in 1.1.4 the definition of the metasymbols
{} implies left associativity. So this could be seen as redundant,
depending on how literally one interprets the definition of the {}
metasymbols.
8.b See the Implementation Permissions below regarding flexibility in
reassociating operators of the same precedence.
9 For each form of type definition, certain of the above operators are
predefined; that is, they are implicitly declared immediately after the type
definition. For each such implicit operator declaration, the parameters are
called Left and Right for binary operators; the single parameter is called
Right for unary operators. [An expression of the form X op Y, where op is a
binary operator, is equivalent to a function_call of the form "op"(X, Y). An
expression of the form op Y, where op is a unary operator, is equivalent to a
function_call of the form "op"(Y). The predefined operators and their effects
are described in subclauses 4.5.1 through 4.5.6.]
Dynamic Semantics
10 [ The predefined operations on integer types either yield the
mathematically correct result or raise the exception Constraint_Error. For
implementations that support the Numerics Annex, the predefined operations on
real types yield results whose accuracy is defined in Annex G, or raise the
exception Constraint_Error. ]
10.a To be honest: Predefined operations on real types can "
silently" give wrong results when the Machine_Overflows attribute is
false, and the computation overflows.
Implementation Requirements
11 The implementation of a predefined operator that delivers a result of an
integer or fixed point type may raise Constraint_Error only if the result is
outside the base range of the result type.
12 The implementation of a predefined operator that delivers a result of a
floating point type may raise Constraint_Error only if the result is outside
the safe range of the result type.
12.a To be honest: An exception is made for exponentiation by a
negative exponent in 4.5.6.
Implementation Permissions
13 For a sequence of predefined operators of the same precedence level (and
in the absence of parentheses imposing a specific association), an
implementation may impose any association of the operators with operands so
long as the result produced is an allowed result for the left-to-right
association, but ignoring the potential for failure of language-defined checks
in either the left-to-right or chosen order of association.
13.a Discussion: Note that the permission to reassociate the operands
in any way subject to producing a result allowed for the
left-to-right association is not much help for most floating point
operators, since reassociation may introduce significantly
different round-off errors, delivering a result that is outside
the model interval for the left-to-right association. Similar
problems arise for division with integer or fixed point operands.
13.b Note that this permission does not apply to user-defined
operators.
NOTES
14 12 The two operands of an expression of the form X op Y, where op is
a binary operator, are evaluated in an arbitrary order, as for any
function_call (see 6.4).
Examples
15 Examples of precedence:
16 not Sunny or Warm -- same as (not Sunny) or Warm
X > 4.0 and Y > 0.0 -- same as (X > 4.0) and (Y > 0.0)
17 -4.0*A**2 -- same as -(4.0 * (A**2))
abs(1 + A) + B -- same as (abs (1 + A)) + B
Y**(-3) -- parentheses are necessary
A / B * C -- same as (A/B)*C
A + (B + C) -- evaluate B + C before adding it to A
Wording Changes from Ada 83
17.a We don't give a detailed definition of precedence, since it is all
implicit in the syntax rules anyway.
17.b The permission to reassociate is moved here from RM83-11.6(5), so
it is closer to the rules defining operator association.
4.5.1 Logical Operators and Short-circuit Control Forms
Name Resolution Rules
1 An expression consisting of two relations connected by and then or or else
(a short-circuit control form) shall resolve to be of some boolean type; the
expected type for both relations is that same boolean type.
1.a Reason: This rule is written this way so that overload resolution
treats the two operands symmetrically; the resolution of
overloading present in either one can benefit from the resolution
of the other. Furthermore, the type expected by context can help.
Static Semantics
2 The following logical operators are predefined for every boolean type T,
for every modular type T, and for every one-dimensional array type T whose
component type is a boolean type:
3 function "and"(Left, Right : T) return T
function "or" (Left, Right : T) return T
function "xor"(Left, Right : T) return T
3.a/2 This paragraph was deleted.{AI95-00145-01}
3.b/2 Ramification: {AI95-00145-01} For these operators, we are talking
about the type without any (interesting) subtype, and not some
subtype with a constraint or exclusion. Since it's possible that
there is no name for the "uninteresting" subtype, we denote the
type with an italicized T. This applies to the italicized T in
many other predefined operators and attributes as well.
3.c/2 {AI95-00145-01} In many cases, there is a subtype with the correct
properties available. The italicized T means:
3.d/2 * T'Base, for scalars;
3.e/2 * the first subtype of T, for tagged types;
3.f/2 * a subtype of the type T without any constraint or null
exclusion, in other cases.
3.g/2 Note that "without a constraint" is not the same as unconstrained.
For instance, a record type with no discriminant part is
considered constrained; no subtype of it has a constraint, but the
subtype is still constrained.
3.h/2 Thus, the last case often is the same as the first subtype of T,
but that isn't the case for constrained array types (where the
correct subtype is unconstrained) and for access types with a
null_exclusion (where the correct subtype does not exclude null).
3.i/2 This italicized T is used for defining operators and attributes of
the language. The meaning is intended to be as described here.
4 For boolean types, the predefined logical operators and, or, and xor
perform the conventional operations of conjunction, inclusive disjunction, and
exclusive disjunction, respectively.
5 For modular types, the predefined logical operators are defined on a
bit-by-bit basis, using the binary representation of the value of the operands
to yield a binary representation for the result, where zero represents False
and one represents True. If this result is outside the base range of the type,
a final subtraction by the modulus is performed to bring the result into the
base range of the type.
6 The logical operators on arrays are performed on a component-by-component
basis on matching components (as for equality - see 4.5.2), using the
predefined logical operator for the component type. The bounds of the
resulting array are those of the left operand.
Dynamic Semantics
7 The short-circuit control forms and then and or else deliver the same
result as the corresponding predefined and and or operators for boolean types,
except that the left operand is always evaluated first, and the right operand
is not evaluated if the value of the left operand determines the result.
8 For the logical operators on arrays, a check is made that for each
component of the left operand there is a matching component of the right
operand, and vice versa. Also, a check is made that each component of the
result belongs to the component subtype. The exception Constraint_Error is
raised if either of the above checks fails.
8.a Discussion: The check against the component subtype is per
AI83-00535.
NOTES
9 13 The conventional meaning of the logical operators is given by the
following truth table:
10 A B (A and B)
(A or B) (A xor B)
True True True
True False
True False False
True True
False True False
True True
False False False
False False
Examples
11 Examples of logical operators:
12 Sunny or Warm
Filter(1 .. 10) and Filter(15 .. 24) -- see 3.6.1
13 Examples of short-circuit control forms:
14 Next_Car.Owner /= null and then Next_Car.Owner.Age > 25 -- see 3.10.1
N = 0 or else A(N) = Hit_Value
4.5.2 Relational Operators and Membership Tests
1 [ The equality operators = (equals) and /= (not equals) are predefined for
nonlimited types. The other relational_operators are the ordering operators <
(less than), <= (less than or equal), > (greater than), and >= (greater than
or equal). The ordering operators are predefined for scalar types, and for
discrete array types, that is, one-dimensional array types whose components
are of a discrete type.
1.a Ramification: The equality operators are not defined for every
nonlimited type - see below for the exact rule.
2/3 {AI05-0262-1} {AI05-0269-1} A membership test, using in or not in,
determines whether or not a value belongs to any given subtype or range, is
equal to any given value, has a tag that identifies a type that is covered by
a given type, or is convertible to and has an accessibility level appropriate
for a given access type. Membership tests are allowed for all types.]
Name Resolution Rules
3/3 {AI95-00251-01} {AI05-0158-1} The tested type of a membership test is
determined by the membership_choices of the membership_choice_list. Either all
membership_choices of the membership_choice_list shall resolve to the same
type, which is the tested type; or each membership_choice shall be of an
elementary type, and the tested type shall be covered by each of these
elementary types.
3.1/4 {AI05-0158-1} {AI12-0039-1} If the tested type is tagged, then the
tested_simple_expression shall resolve to be of a type that is convertible
(see 4.6) to the tested type; if untagged, the expected type for the
tested_simple_expression is the tested type. The expected type of a
choice_simple_expression in a membership_choice, and of a simple_expression of a
range in a membership_choice, is the tested type of the membership operation.
3.a/2 Reason: {AI95-00230-01} The part of the rule for untagged types is
stated in a way that ensures that operands like a string literal
are still legal as operands of a membership test.
3.b/4 {AI95-00251-01} {AI12-0039-1} The significance of "is convertible
to" is that we allow the tested_simple_expression to be of any
class-wide type that could be converted to the tested type, not
just the one rooted at the tested type. This includes any
class-wide type that covers the tested type, along with class-wide
interfaces in some cases.
3.c/3 {AI05-0158-1} The special rule for determining the tested type for
elementary types is to allow numeric literals in
membership_choice_lists. Without the rule, A in B | 1 would be
illegal as B and 1 would have different types (the literal having
type universal integer).
Legality Rules
4/4 {AI12-0039-1} For a membership test, if the tested_simple_expression is of
a tagged class-wide type, then the tested type shall be (visibly) tagged.
4.a Ramification: Untagged types covered by the tagged class-wide type
are not permitted. Such types can exist if they are descendants of
a private type whose full type is tagged. This rule is intended to
avoid confusion since such derivatives don't have their "own" tag,
and hence are indistinguishable from one another at run time once
converted to a covering class-wide type.
4.1/4 {AI05-0158-1} {AI12-0039-1} If a membership test includes one or more
choice_simple_expressions and the tested type of the membership test is
limited, then the tested type of the membership test shall have a visible
primitive equality operator.
4.b/3 Reason: {AI05-0158-1} A visible equality operator is required in
order to avoid breaking privacy; that is, we don't want to depend
on a hidden equality operator.
Static Semantics
5 The result type of a membership test is the predefined type Boolean.
6 The equality operators are predefined for every specific type T that is
not limited, and not an anonymous access type, with the following
specifications:
7 function "=" (Left, Right : T) return Boolean
function "/="(Left, Right : T) return Boolean
7.1/2 {AI95-00230-01} The following additional equality operators for the
universal_access type are declared in package Standard for use with anonymous
access types:
7.2/2 function "=" (Left, Right : universal_access) return Boolean
function "/="(Left, Right : universal_access) return Boolean
8 The ordering operators are predefined for every specific scalar type T,
and for every discrete array type T, with the following specifications:
9 function "<" (Left, Right : T) return Boolean
function "<="(Left, Right : T) return Boolean
function ">" (Left, Right : T) return Boolean
function ">="(Left, Right : T) return Boolean
Name Resolution Rules
9.1/2 {AI95-00230-01} {AI95-00420-01} At least one of the operands of an
equality operator for universal_access shall be of a specific anonymous access
type. Unless the predefined equality operator is identified using an expanded
name with prefix denoting the package Standard, neither operand shall be of an
access-to-object type whose designated type is D or D'Class, where D has a
user-defined primitive equality operator such that:
9.2/2 * its result type is Boolean;
9.3/3 * {AI05-0020-1} it is declared immediately within the same declaration
list as D or any partial or incomplete view of D; and
9.4/2 * at least one of its operands is an access parameter with designated
type D.
9.a/2 Reason: The first sentence prevents compatibility problems by
ensuring that these operators are not used for named access types.
Also, universal access types do not count for the purposes of this
rule. Otherwise, equality expressions like (X = null) would be
ambiguous for normal access types.
9.b/2 The rest of the rule makes it possible to call (including a
dispatching call) user-defined "=" operators for anonymous
access-to-object types (they'd be hidden otherwise), and to write
user-defined "=" operations for anonymous access types (by making
it possible to see the universal operator using the Standard
prefix).
9.c/2 Ramification: We don't need a similar rule for anonymous
access-to-subprogram types because they can't be primitive for any
type. Note that any nonprimitive user-defined equality operators
still are hidden by the universal operators; they'll have to be
called with a package prefix, but they are likely to be very
uncommon.
Legality Rules
9.5/2 {AI95-00230-01} At least one of the operands of the equality operators
for universal_access shall be of type universal_access, or both shall be of
access-to-object types, or both shall be of access-to-subprogram types.
Further:
9.6/2 * When both are of access-to-object types, the designated types shall
be the same or one shall cover the other, and if the designated types
are elementary or array types, then the designated subtypes shall
statically match;
9.7/2 * When both are of access-to-subprogram types, the designated profiles
shall be subtype conformant.
9.d/2 Reason: We don't want to allow completely arbitrary comparisons,
as we don't want to insist that all access types are represented
in ways that are convertible to one another. For instance, a
compiler could use completely separate address spaces or
incompatible representations. Instead, we allow compares if there
exists an access parameter to which both operands could be
converted. Since the user could write such an subprogram, and any
reasonable meaning for "=" would allow using it in such a
subprogram, this doesn't impose any further restrictions on Ada
implementations.
9.8/4 {AI05-0123-1} {AI12-0101-1} If the profile of an explicitly declared
primitive equality operator of an untagged record type is type conformant with
that of the corresponding predefined equality operator, the declaration shall
occur before the type is frozen. In addition to the places where
Legality Rules normally apply (see 12.3), this rule applies also in the
private part of an instance of a generic unit.
Dynamic Semantics
10 For discrete types, the predefined relational operators are defined in
terms of corresponding mathematical operations on the position numbers of the
values of the operands.
11 For real types, the predefined relational operators are defined in terms
of the corresponding mathematical operations on the values of the operands,
subject to the accuracy of the type.
11.a Ramification: For floating point types, the results of comparing
nearly equal values depends on the accuracy of the implementation
(see G.2.1, "Model of Floating Point Arithmetic" for
implementations that support the Numerics Annex).
11.b Implementation Note: On a machine with signed zeros, if the
generated code generates both plus zero and minus zero, plus and
minus zero must be equal by the predefined equality operators.
12 Two access-to-object values are equal if they designate the same object,
or if both are equal to the null value of the access type.
13 Two access-to-subprogram values are equal if they are the result of the
same evaluation of an Access attribute_reference, or if both are equal to the
null value of the access type. Two access-to-subprogram values are unequal if
they designate different subprograms. [It is unspecified whether two access
values that designate the same subprogram but are the result of distinct
evaluations of Access attribute_references are equal or unequal.]
13.a Reason: This allows each Access attribute_reference for a
subprogram to designate a distinct "wrapper" subprogram if
necessary to support an indirect call.
14/3 {AI05-0123-1} For a type extension, predefined equality is defined in
terms of the primitive [(possibly user-defined)] equals operator for the
parent type and for any components that have a record type in the extension
part, and predefined equality for any other components not inherited from the
parent type.
14.a Ramification: Two values of a type extension are not equal if
there is a variant_part in the extension part and the two values
have different variants present. This is a ramification of the
requirement that a discriminant governing such a variant_part has
to be a "new" discriminant, and so has to be equal in the two
values for the values to be equal. Note that variant_parts in the
parent part need not match if the primitive equals operator for
the parent type considers them equal.
14.b/2 {AI95-00349-01} The full type extension's operation is used for a
private extension. This follows as only full types have parent
types; the type specified in a private extension is an ancestor,
but not necessarily the parent type. For instance, in:
14.c/2 with Pak1;
package Pak2 is
type Typ3 is new Pak1.Typ1 with private;
private
type Typ3 is new Pak1.Typ2 with null record;
end Pak2;
14.d/2 the parent type is Pak1.Typ2, not Pak1.Typ1, and the equality
operator of Pak1.Typ2 is used to create predefined equality for
Typ3.
14.1/3 {AI05-0123-1} For a derived type whose parent is an untagged record
type, predefined equality is defined in terms of the primitive (possibly
user-defined) equals operator of the parent type.
14.e/3 Reason: This prevents predefined equality from reemerging in
generic units for untagged record types. For other uses the
primitive equality is inherited and the inherited routine is
primitive.
15/3 {AI05-0123-1} For a private type, if its full type is a record type,
predefined equality is defined in terms of the primitive equals operator of
the full type; otherwise, predefined equality for the private type is that of
its full type.
16 For other composite types, the predefined equality operators [(and certain
other predefined operations on composite types - see 4.5.1 and 4.6)] are
defined in terms of the corresponding operation on matching components,
defined as follows:
17 * For two composite objects or values of the same non-array type,
matching components are those that correspond to the same
component_declaration or discriminant_specification;
18 * For two one-dimensional arrays of the same type, matching components
are those (if any) whose index values match in the following sense:
the lower bounds of the index ranges are defined to match, and the
successors of matching indices are defined to match;
19 * For two multidimensional arrays of the same type, matching components
are those whose index values match in successive index positions.
20 The analogous definitions apply if the types of the two objects or values
are convertible, rather than being the same.
20.a Discussion: Ada 83 seems to omit this part of the definition,
though it is used in array type conversions. See 4.6.
21 Given the above definition of matching components, the result of the
predefined equals operator for composite types (other than for those composite
types covered earlier) is defined as follows:
22 * If there are no components, the result is defined to be True;
23 * If there are unmatched components, the result is defined to be False;
24/3 * {AI05-0123-1} Otherwise, the result is defined in terms of the
primitive equals operator for any matching components that are
records, and the predefined equals for any other matching components.
24.a/3 Reason: {AI05-0123-1} This asymmetry between components with and
without a record type is necessary to preserve most upward
compatibility and corresponds with the corresponding situation
with generics, where the predefined operations "reemerge" in a
generic for non-record types, but do not for record types. Also,
only tagged types support user-defined assignment (see 7.6), so
only tagged types can fully handle levels of indirection in the
implementation of the type. For untagged types, one reason for a
user-defined equals operator might be to allow values with
different bounds or discriminants to compare equal in certain
cases. When such values are matching components, the bounds or
discriminants will necessarily match anyway if the discriminants
of the enclosing values match.
24.b Ramification: Two null arrays of the same type are always equal;
two null records of the same type are always equal.
24.c/3 {AI05-0123-1} Note that if a composite object has a component of a
floating point type, and the floating point type has both a plus
and minus zero, which are considered equal by the predefined
equality, then a block compare cannot be used for the predefined
composite equality. Of course, with user-defined equals operators
for components that are records, a block compare breaks down
anyway, so this is not the only special case that requires
component-by-component comparisons. On a one's complement machine,
a similar situation might occur for integer types, since one's
complement machines typically have both a plus and minus (integer)
zero.
24.d/2 To be honest: {AI95-00230-01} For a component with an anonymous
access type, "predefined equality" is that defined for the
universal_access type (anonymous access types have no equality
operators of their own).
24.e/3 {AI05-0123-1} For a component with a record type T, "the primitive
equals operator" is the one with two parameters of T which returns
Boolean. We're not talking about some random other primitive
function named "=".
24.1/3 {AI05-0123-1} If the primitive equals operator for an untagged record
type is abstract, then Program_Error is raised at the point of any (implicit)
call to that abstract subprogram.
24.f/3 Reason: An explicit call to an abstract subprogram is illegal.
This rule is needed in order to define the effect of an implicit
call such as a call that is part of the predefined equality
operation for an enclosing composite type that has a component of
an untagged record type that has an abstract primitive equals
operator. For tagged types, an abstract primitive equals operator
is only allowed for an abstract type, and abstract types cannot be
components, so this case does not occur.
24.2/1 {8652/0016} {AI95-00123-01} For any composite type, the order in which
"=" is called for components is unspecified. Furthermore, if the result can be
determined before calling "=" on some components, it is unspecified whether
"=" is called on those components.
25 The predefined "/=" operator gives the complementary result to the
predefined "=" operator.
25.a Ramification: Furthermore, if the user defines an "=" operator
that returns Boolean, then a "/=" operator is implicitly declared
in terms of the user-defined "=" operator so as to give the
complementary result. See 6.6.
26/3 {AI05-0264-1} For a discrete array type, the predefined ordering
operators correspond to lexicographic order using the predefined order
relation of the component type: A null array is lexicographically less than
any array having at least one component. In the case of nonnull arrays, the
left operand is lexicographically less than the right operand if the first
component of the left operand is less than that of the right; otherwise, the
left operand is lexicographically less than the right operand only if their
first components are equal and the tail of the left operand is
lexicographically less than that of the right (the tail consists of the
remaining components beyond the first and can be null).
26.1/3 {AI05-0269-1} An individual membership test is the membership test of a
single membership_choice.
27/4 {AI05-0158-1} {AI12-0039-1} For the evaluation of a membership test using
in whose membership_choice_list has a single membership_choice, the
tested_simple_expression and the membership_choice are evaluated in an arbitrary
order; the result is the result of the individual membership test for the
membership_choice.
27.1/4 {AI05-0158-1} {AI12-0039-1} For the evaluation of a membership test
using in whose membership_choice_list has more than one membership_choice, the
tested_simple_expression of the membership test is evaluated first and the
result of the operation is equivalent to that of a sequence consisting of an
individual membership test on each membership_choice combined with the
short-circuit control form or else.
27.a.1/3 Ramification: {AI05-0158-1} This equivalence includes the
evaluation of the membership_choices; evaluation stops as soon as
an individual choice evaluates to True.
28/3 {AI05-0158-1} {AI05-0269-1} An individual membership test yields the
result True if:
28.1/4 * {AI05-0158-1} {AI05-0264-1} {AI12-0039-1} The membership_choice is
a choice_simple_expression, and the tested_simple_expression is equal
to the value of the membership_choice. If the tested type is a record
type or a limited type, the test uses the primitive equality for the
type; otherwise, the test uses predefined equality.
28.2/4 * {AI05-0153-3} {AI05-0158-1} {AI12-0039-1} The membership_choice is
a range and the value of the tested_simple_expression belongs to the
given range.
29/4 * {AI05-0153-3} {AI05-0158-1} {AI12-0039-1} {AI12-0071-1} The
membership_choice is a subtype_mark, the tested type is scalar, the
value of the tested_simple_expression belongs to the range of the
named subtype, and the value satisfies the predicates of the named
subtype.
29.a/3 Ramification: {AI05-0153-3} The scalar membership test only does a
range check and a predicate check. It does not perform any other
check, such as whether a value falls in a "hole" of a "holey"
enumeration type. The Pos attribute function can be used for that
purpose.
29.b Even though Standard.Float is an unconstrained subtype, the test
"X in Float" will still return False (presuming the evaluation of
X does not raise Constraint_Error) when X is outside Float'Range.
30/4 * {AI95-00231-01} {AI05-0153-3} {AI05-0158-1} {AI12-0039-1}
{AI12-0071-1} The membership_choice is a subtype_mark, the tested type
is not scalar, the value of the tested_simple_expression satisfies any
constraints of the named subtype, the value satisfies the predicates
of the named subtype, and:
30.1/4 * {AI95-00231-01} {AI12-0039-1} if the type of the
tested_simple_expression is class-wide, the value has a tag that
identifies a type covered by the tested type;
30.a/4 Ramification: {AI12-0039-1} Note that the tag is not checked if
the tested_simple_expression is of a specific type.
30.2/4 * {AI95-00231-01} {AI05-0149-1} {AI12-0039-1} if the tested type is
an access type and the named subtype excludes null, the value of
the tested_simple_expression is not null;
30.3/4 * {AI05-0149-1} {AI12-0039-1} if the tested type is a general
access-to-object type, the type of the tested_simple_expression is
convertible to the tested type and its accessibility level is no
deeper than that of the tested type; further, if the designated
type of the tested type is tagged and the
tested_simple_expression is nonnull, the tag of the object designated by
the value of the tested_simple_expression is covered by the
designated type of the tested type.
31/3 {AI05-0264-1} Otherwise, the test yields the result False.
32 A membership test using not in gives the complementary result to the
corresponding membership test using in.
32.a/4 To be honest: {AI05-0158-1} {AI12-0039-1} X not in A | B | C is
intended to be exactly equivalent to not (X in A | B | C),
including the order of evaluation of the
tested_simple_expression and membership_choices.
Implementation Requirements
32.1/1 {8652/0016} {AI95-00123-01} For all nonlimited types declared in
language-defined packages, the "=" and "/=" operators of the type shall behave
as if they were the predefined equality operators for the purposes of the
equality of composite types and generic formal types.
32.a.1/3 Ramification: {AI95-00123-01} {AI05-0123-1} If any
language-defined types are implemented with a user-defined "="
operator, then either the full type must be a record type, or the
compiler must use "magic" to implement equality for this type. A
normal user-defined "=" operator for a non-record type does not
meet this requirement.
NOTES
33/2 This paragraph was deleted.{AI95-00230-01}
34 14 If a composite type has components that depend on discriminants,
two values of this type have matching components if and only if their
discriminants are equal. Two nonnull arrays have matching components
if and only if the length of each dimension is the same for both.
Examples
35 Examples of expressions involving relational operators and membership
tests:
36 X /= Y
37 "" < "A" and "A" < "Aa" -- True
"Aa" < "B" and "A" < "A " -- True
38/3 {AI05-0264-1}
My_Car = null -- True if My_Car has been set to null (see 3.10.1
)
My_Car = Your_Car -- True if we both share the same car
My_Car.all = Your_Car.all -- True if the two cars are identical
39/3 {AI05-0158-1} N not in 1 .. 10 -- range membership test
Today in Mon .. Fri -- range membership test
Today in Weekday -- subtype membership test (see 3.5.1)
Card in Clubs | Spades -- list membership test (see 3.5.1)
Archive in Disk_Unit -- subtype membership test (see 3.8.1)
Tree.all in Addition'Class -- class membership test (see 3.9.1)
Extensions to Ada 83
39.a Membership tests can be used to test the tag of a class-wide value.
39.b Predefined equality for a composite type is defined in terms of
the primitive equals operator for tagged components or the parent
part.
Wording Changes from Ada 83
39.c The term "membership test" refers to the relation "X in S" rather
to simply the reserved word in or not in.
39.d We use the term "equality operator" to refer to both the =
(equals) and /= (not equals) operators. Ada 83 referred to = as
the equality operator, and /= as the inequality operator. The new
wording is more consistent with the ISO 10646 name for "=" (equals
sign) and provides a category similar to "ordering operator" to
refer to both = and /=.
39.e We have changed the term "catenate" to "concatenate".
Extensions to Ada 95
39.f/2 {AI95-00230-01} {AI95-00420-01} The universal_access equality
operators are new. They provide equality operations (most
importantly, testing against null) for anonymous access types.
Wording Changes from Ada 95
39.g/2 {8652/0016} {AI95-00123-01} Corrigendum: Wording was added to
clarify that the order of calls (and whether the calls are made at
all) on "=" for components is unspecified. Also clarified that "="
must compose properly for language-defined types.
39.h/2 {AI95-00251-01} Memberships were adjusted to allow interfaces
which don't cover the tested type, in order to be consistent with
type conversions.
Inconsistencies With Ada 2005
39.i/3 {AI05-0123-1} User-defined untagged record equality is now defined
to compose and be used in generics. Any code which assumes that
the predefined equality reemerges in generics and in predefined
equals for composite types could fail. However, it is much more
likely that this change will fix bugs, as the behavior that would
be expected (the user-defined "=" is used) will be true in more
cases.
39.j/3 {AI05-0123-1} If a composite type contains a component of an
untagged record type with an abstract equality operation, calling
"=" on the composite type will raise Program_Error, while in the
past a result will be returned using the predefined equality. This
is quite possible in ASIS programs; it will detect a bug in such
programs but of course the programs will need to be fixed before
they will work.
Incompatibilities With Ada 2005
39.k/3 {AI05-0123-1} Late and hidden overriding of equality for untagged
record types is now prohibited. This is necessary to make
composition of equality predictable. It should always be possible
to move the overriding to an earlier spot where it will be legal.
Extensions to Ada 2005
39.l/3 {AI05-0149-1} Membership tests for valid accessibility levels and
tag coverage by the designated type for general access types are
new.
39.m/3 {AI05-0153-3} Membership tests now include a predicate check.
39.n/3 {AI05-0158-1} Membership tests now allow multiple choices.
Wording Changes from Ada 2005
39.o/3 {AI05-0020-1} Correction: Wording was added to clarify that
universal_access "=" does not apply if an appropriate operator is
declared for a partial or incomplete view of the designated type.
Otherwise, adding a partial or incomplete view could make some "="
operators ambiguous.
Inconsistencies With Ada 2012
39.p/4 {AI12-0101-1} Corrigendum: Removed the incompatible rule
preventing the declaration of "=" in the private part of a package
specification for an untagged record type that completes a private
type. Any code that calls the predefined "=" on the private type
will now execute the body for the redefined "=" instead for the
predefined "=". Eliminating the rule eliminates an unnecessary
incompatibility (especially for programs that never call the
predefined "="). Moreover, (like the composition of untagged
record "=" in Ada 2012) this is more likely to fix bugs than cause
them (who defines an "=" with a presumably different result and
does not want clients to us it?).
Wording Changes from Ada 2012
39.q/4 {AI12-0039-1} Corrigendum: Reworded membership tests to use the
syntax items tested_simple_expression and
choice_simple_expression. This was necessary to eliminate wording
ambiguities introduced when the grammar was corrected to eliminate
syntax ambiguities. (Both of the above are now simple_expression
s, so merely talking about a simple_expression is insufficient.)
39.r/4 {AI12-0071-1} Corrigendum: Updated wording of the membership tests
to use the new term "satisfies the predicates" (see 3.2.4).
4.5.3 Binary Adding Operators
Static Semantics
1 The binary adding operators + (addition) and - (subtraction) are
predefined for every specific numeric type T with their conventional meaning.
They have the following specifications:
2 function "+"(Left, Right : T) return T
function "-"(Left, Right : T) return T
3 The concatenation operators & are predefined for every nonlimited,
one-dimensional array type T with component type C. They have the following
specifications:
4 function "&"(Left : T; Right : T) return T
function "&"(Left : T; Right : C) return T
function "&"(Left : C; Right : T) return T
function "&"(Left : C; Right : C) return T
Dynamic Semantics
5 For the evaluation of a concatenation with result type T, if both operands
are of type T, the result of the concatenation is a one-dimensional array
whose length is the sum of the lengths of its operands, and whose components
comprise the components of the left operand followed by the components of the
right operand. If the left operand is a null array, the result of the
concatenation is the right operand. Otherwise, the lower bound of the result
is determined as follows:
6 * If the ultimate ancestor of the array type was defined by a
constrained_array_definition, then the lower bound of the result is
that of the index subtype;
6.a Reason: This rule avoids Constraint_Error when using concatenation
on an array type whose first subtype is constrained.
7 * If the ultimate ancestor of the array type was defined by an
unconstrained_array_definition, then the lower bound of the result is
that of the left operand.
8 [The upper bound is determined by the lower bound and the length.] A check
is made that the upper bound of the result of the concatenation belongs to the
range of the index subtype, unless the result is a null array.
Constraint_Error is raised if this check fails.
9 If either operand is of the component type C, the result of the
concatenation is given by the above rules, using in place of such an operand
an array having this operand as its only component (converted to the component
subtype) and having the lower bound of the index subtype of the array type as
its lower bound.
9.a Ramification: The conversion might raise Constraint_Error. The
conversion provides "sliding" for the component in the case of an
array-of-arrays, consistent with the normal Ada 95 rules that
allow sliding during parameter passing.
10 The result of a concatenation is defined in terms of an assignment to an
anonymous object, as for any function call (see 6.5).
10.a Ramification: This implies that value adjustment is performed as
appropriate - see 7.6. We don't bother saying this for other
predefined operators, even though they are all function calls,
because this is the only one where it matters. It is the only one
that can return a value having controlled parts.
NOTES
11 15 As for all predefined operators on modular types, the binary
adding operators + and - on modular types include a final reduction
modulo the modulus if the result is outside the base range of the
type.
11.a Implementation Note: A full "modulus" operation need not be
performed after addition or subtraction of modular types. For
binary moduli, a simple mask is sufficient. For nonbinary moduli,
a check after addition to see if the value is greater than the
high bound of the base range can be followed by a conditional
subtraction of the modulus. Conversely, a check after subtraction
to see if a "borrow" was performed can be followed by a
conditional addition of the modulus.
Examples
12 Examples of expressions involving binary adding operators:
13 Z + 0.1 -- Z has to be of a real type
14 "A" & "BCD" -- concatenation of two string literals
'A' & "BCD" -- concatenation of a character literal and a string literal
'A' & 'A' -- concatenation of two character literals
Inconsistencies With Ada 83
14.a The lower bound of the result of concatenation, for a type whose
first subtype is constrained, is now that of the index subtype.
This is inconsistent with Ada 83, but generally only for Ada 83
programs that raise Constraint_Error. For example, the
concatenation operator in
14.b X : array(1..10) of Integer;
begin
X := X(6..10) & X(1..5);
14.c would raise Constraint_Error in Ada 83 (because the bounds of the
result of the concatenation would be 6..15, which is outside of
1..10), but would succeed and swap the halves of X (as expected)
in Ada 95.
Extensions to Ada 83
14.d Concatenation is now useful for array types whose first subtype is
constrained. When the result type of a concatenation is such an
array type, Constraint_Error is avoided by effectively first
sliding the left operand (if nonnull) so that its lower bound is
that of the index subtype.
4.5.4 Unary Adding Operators
Static Semantics
1 The unary adding operators + (identity) and - (negation) are predefined
for every specific numeric type T with their conventional meaning. They have
the following specifications:
2 function "+"(Right : T) return T
function "-"(Right : T) return T
NOTES
3 16 For modular integer types, the unary adding operator -, when given
a nonzero operand, returns the result of subtracting the value of the
operand from the modulus; for a zero operand, the result is zero.
4.5.5 Multiplying Operators
Static Semantics
1 The multiplying operators * (multiplication), / (division), mod (modulus),
and rem (remainder) are predefined for every specific integer type T:
2 function "*" (Left, Right : T) return T
function "/" (Left, Right : T) return T
function "mod"(Left, Right : T) return T
function "rem"(Left, Right : T) return T
3 Signed integer multiplication has its conventional meaning.
4 Signed integer division and remainder are defined by the relation:
5 A = (A/B)*B + (A rem B)
6 where (A rem B) has the sign of A and an absolute value less than the
absolute value of B. Signed integer division satisfies the identity:
7 (-A)/B = -(A/B) = A/(-B)
8/3 {AI05-0260-1} The signed integer modulus operator is defined such that the
result of A mod B is either zero, or has the sign of B and an absolute value
less than the absolute value of B; in addition, for some signed integer value
N, this result satisfies the relation:
9 A = B*N + (A mod B)
10 The multiplying operators on modular types are defined in terms of the
corresponding signed integer operators[, followed by a reduction modulo the
modulus if the result is outside the base range of the type] [(which is only
possible for the "*" operator)].
10.a Ramification: The above identity satisfied by signed integer
division is not satisfied by modular division because of the
difference in effect of negation.
11 Multiplication and division operators are predefined for every specific
floating point type T:
12 function "*"(Left, Right : T) return T
function "/"(Left, Right : T) return T
13 The following multiplication and division operators, with an operand of
the predefined type Integer, are predefined for every specific fixed point
type T:
14 function "*"(Left : T; Right : Integer) return T
function "*"(Left : Integer; Right : T) return T
function "/"(Left : T; Right : Integer) return T
15 [All of the above multiplying operators are usable with an operand of an
appropriate universal numeric type.] The following additional multiplying
operators for root_real are predefined[, and are usable when both operands are
of an appropriate universal or root numeric type, and the result is allowed to
be of type root_real, as in a number_declaration]:
15.a Ramification: These operators are analogous to the multiplying
operators involving fixed or floating point types where root_real
substitutes for the fixed or floating point type, and root_integer
substitutes for Integer. Only values of the corresponding
universal numeric types are implicitly convertible to these root
numeric types, so these operators are really restricted to use
with operands of a universal type, or the specified root numeric
types.
16 function "*"(Left, Right : root_real) return root_real
function "/"(Left, Right : root_real) return root_real
17 function "*"(Left : root_real; Right : root_integer) return root_real
function "*"(Left : root_integer; Right : root_real) return root_real
function "/"(Left : root_real; Right : root_integer) return root_real
18 Multiplication and division between any two fixed point types are provided
by the following two predefined operators:
18.a Ramification: Universal_fixed is the universal type for the class
of fixed point types, meaning that these operators take operands
of any fixed point types (not necessarily the same) and return a
result that is implicitly (or explicitly) convertible to any fixed
point type.
19 function "*"(Left, Right : universal_fixed) return universal_fixed
function "/"(Left, Right : universal_fixed) return universal_fixed
Name Resolution Rules
19.1/2 {AI95-00364-01} {AI95-00420-01} The above two fixed-fixed multiplying
operators shall not be used in a context where the expected type for the
result is itself universal_fixed [- the context has to identify some other
numeric type to which the result is to be converted, either explicitly or
implicitly]. Unless the predefined universal operator is identified using an
expanded name with prefix denoting the package Standard, an explicit
conversion is required on the result when using the above fixed-fixed
multiplication operator if either operand is of a type having a user-defined
primitive multiplication operator such that:
19.2/3 * {AI05-0020-1} {AI05-0209-1} it is declared immediately within the
same declaration list as the type or any partial or incomplete view
thereof; and
19.3/2 * both of its formal parameters are of a fixed-point type.
19.4/2 {AI95-00364-01} {AI95-00420-01} A corresponding requirement applies to
the universal fixed-fixed division operator.
19.a/2 Discussion: The small of universal_fixed is infinitesimal; no loss
of precision is permitted. However, fixed-fixed division is
impractical to implement when an exact result is required, and
multiplication will sometimes result in unanticipated overflows in
such circumstances, so we require an explicit conversion to be
inserted in expressions like A * B * C if A, B, and C are each of
some fixed point type.
19.b/2 On the other hand, X := A * B; is permitted by this rule, even if
X, A, and B are all of different fixed point types, since the
expected type for the result of the multiplication is the type of
X, which is necessarily not universal_fixed.
19.c/2 {AI95-00364-01} {AI95-00420-01} We have made these into Name
Resolution rules to ensure that user-defined primitive fixed-fixed
operators are not made unusable due to the presence of these
universal fixed-fixed operators. But we do allow these operators
to be used if prefixed by package Standard, so that they can be
used in the definitions of user-defined operators.
Paragraph 20 was deleted.
Dynamic Semantics
21 The multiplication and division operators for real types have their
conventional meaning. [For floating point types, the accuracy of the result is
determined by the precision of the result type. For decimal fixed point types,
the result is truncated toward zero if the mathematical result is between two
multiples of the small of the specific result type (possibly determined by
context); for ordinary fixed point types, if the mathematical result is
between two multiples of the small, it is unspecified which of the two is the
result. ]
22 The exception Constraint_Error is raised by integer division, rem, and mod
if the right operand is zero. [Similarly, for a real type T with
T'Machine_Overflows True, division by zero raises Constraint_Error.]
NOTES
23 17 For positive A and B, A/B is the quotient and A rem B is the
remainder when A is divided by B. The following relations are
satisfied by the rem operator:
24 A rem (-B) = A rem B
(-A) rem B = -(A rem B)
25 18 For any signed integer K, the following identity holds:
26 A mod B = (A + K*B) mod B
27 The relations between signed integer division, remainder, and modulus
are illustrated by the following table:
28 A B A/B A rem B A mod B A B A/B A rem B A mod B
29 10 5 2 0 0 -10 5 -2 0 0
11 5 2 1 1 -11 5 -2 -1 4
12 5 2 2 2 -12 5 -2 -2 3
13 5 2 3 3 -13 5 -2 -3 2
14 5 2 4 4 -14 5 -2 -4 1
30 A B A/B A rem B A mod B A B A/B A rem B A mod B
10 -5 -2 0 0 -10 -5 2 0 0
11 -5 -2 1 -4 -11 -5 2 -1 -1
12 -5 -2 2 -3 -12 -5 2 -2 -2
13 -5 -2 3 -2 -13 -5 2 -3 -3
14 -5 -2 4 -1 -14 -5 2 -4 -4
Examples
31 Examples of expressions involving multiplying operators:
32 I : Integer := 1;
J : Integer := 2;
K : Integer := 3;
33 X : Real := 1.0; -- see 3.5.7
Y : Real := 2.0;
34 F : Fraction := 0.25; -- see 3.5.9
G : Fraction := 0.5;
35 Expression Value Result Type
I*J 2 same as I and J, that is, Integer
K/J 1 same as K and J, that is, Integer
K mod J 1 same as K and J, that is, Integer
X/Y 0.5 same as X and Y, that is, Real
F/2 0.125 same as F, that is, Fraction
3*F 0.75 same as F, that is, Fraction
0.75*G 0.375
universal_fixed, implicitly convertible
to any fixed point type
Fraction(F*G) 0.125
Fraction, as stated by the conversion
Real(J)*Y 4.0
Real, the type of both operands after
conversion of J
Incompatibilities With Ada 83
35.a.1/2 {AI95-00364-01} {AI95-00420-01} The universal fixed-fixed
multiplying operators are now directly available (see below). Any
attempt to use user-defined fixed-fixed multiplying operators will
be ambiguous with the universal ones. The only way to use the
user-defined operators is to fully qualify them in a prefix call.
This problem was not documented during the design of Ada 95, and
has been mitigated by Ada 2005.
Extensions to Ada 83
35.a Explicit conversion of the result of multiplying or dividing two
fixed point numbers is no longer required, provided the context
uniquely determines some specific fixed point result type. This is
to improve support for decimal fixed point, where requiring
explicit conversion on every fixed-fixed multiply or divide was
felt to be inappropriate.
35.b The type universal_fixed is covered by universal_real, so real
literals and fixed point operands may be multiplied or divided
directly, without any explicit conversions required.
Wording Changes from Ada 83
35.c We have used the normal syntax for function definition rather than
a tabular format.
Incompatibilities With Ada 95
35.d/2 {AI95-00364-01} We have changed the resolution rules for the
universal fixed-fixed multiplying operators to remove the
incompatibility with Ada 83 discussed above. The solution is to
hide the universal operators in some circumstances. As a result,
some legal Ada 95 programs will require the insertion of an
explicit conversion around a fixed-fixed multiply operator. This
change is likely to catch as many bugs as it causes, since it is
unlikely that the user wanted to use predefined operators when
they had defined user-defined versions.
Wording Changes from Ada 2005
35.e/3 {AI05-0020-1} {AI05-0209-1} Correction: Wording was added to
clarify that universal_fixed "*" and "/" does not apply if an
appropriate operator is declared for a partial (or incomplete)
view of the designated type. Otherwise, adding a partial (or
incomplete) view could make some "*" and "/" operators ambiguous.
35.f/3 {AI05-0260-1} Correction: The wording for the mod operator was
corrected so that a result of 0 does not have to have "the sign of
B" (which is impossible if B is negative).
4.5.6 Highest Precedence Operators
Static Semantics
1 The highest precedence unary operator abs (absolute value) is predefined
for every specific numeric type T, with the following specification:
2 function "abs"(Right : T) return T
3 The highest precedence unary operator not (logical negation) is predefined
for every boolean type T, every modular type T, and for every one-dimensional
array type T whose components are of a boolean type, with the following
specification:
4 function "not"(Right : T) return T
5 The result of the operator not for a modular type is defined as the
difference between the high bound of the base range of the type and the value
of the operand. [For a binary modulus, this corresponds to a bit-wise
complement of the binary representation of the value of the operand.]
6 The operator not that applies to a one-dimensional array of boolean
components yields a one-dimensional boolean array with the same bounds; each
component of the result is obtained by logical negation of the corresponding
component of the operand (that is, the component that has the same index
value). A check is made that each component of the result belongs to the
component subtype; the exception Constraint_Error is raised if this check
fails.
6.a Discussion: The check against the component subtype is per
AI83-00535.
7 The highest precedence exponentiation operator ** is predefined for every
specific integer type T with the following specification:
8 function "**"(Left : T; Right : Natural) return T
9 Exponentiation is also predefined for every specific floating point type
as well as root_real, with the following specification (where T is root_real
or the floating point type):
10 function "**"(Left : T; Right : Integer'Base) return T
11/3 {AI05-0088-1} The right operand of an exponentiation is the exponent. The
value of X**N with the value of the exponent N positive is the same as the
value of X*X*...X (with N-1 multiplications) except that the multiplications
are associated in an arbitrary order. With N equal to zero, the result is one.
With the value of N negative [(only defined for a floating point operand)],
the result is the reciprocal of the result using the absolute value of N as
the exponent.
11.a Ramification: The language does not specify the order of
association of the multiplications inherent in an exponentiation.
For a floating point type, the accuracy of the result might depend
on the particular association order chosen.
Implementation Permissions
12 The implementation of exponentiation for the case of a negative exponent
is allowed to raise Constraint_Error if the intermediate result of the
repeated multiplications is outside the safe range of the type, even though
the final result (after taking the reciprocal) would not be. (The best machine
approximation to the final result in this case would generally be 0.0.)
NOTES
13 19 As implied by the specification given above for exponentiation of
an integer type, a check is made that the exponent is not negative.
Constraint_Error is raised if this check fails.
Inconsistencies With Ada 83
13.a.1/1 {8652/0100} {AI95-00018-01} The definition of "**" allows
arbitrary association of the multiplications which make up the
result. Ada 83 required left-to-right associations (confirmed by
AI83-00137). Thus it is possible that "**" would provide a
slightly different (and more potentially accurate) answer in Ada
95 than in the same Ada 83 program.
Wording Changes from Ada 83
13.a We now show the specification for "**" for integer types with a
parameter subtype of Natural rather than Integer for the exponent.
This reflects the fact that Constraint_Error is raised if a
negative value is provided for the exponent.
Wording Changes from Ada 2005
13.b/3 {AI05-0088-1} Correction: The equivalence definition for "**" was
corrected so that it does not imply that the operands are
evaluated multiple times.
4.5.7 Conditional Expressions
1/3 {AI05-0147-1} {AI05-0188-1} {AI05-0262-1} A conditional_expression selects
for evaluation at most one of the enclosed dependent_expressions, depending on
a decision among the alternatives. One kind of conditional_expression is the
if_expression, which selects for evaluation a dependent_expression depending
on the value of one or more corresponding conditions. The other kind of
conditional_expression is the case_expression, which selects for evaluation
one of a number of alternative dependent_expressions; the chosen alternative
is determined by the value of a selecting_expression.
Language Design Principles
1.a/3 {AI05-0188-1} As previously noted, there are two kinds of
conditional_expression, if_expressions and case_expressions.
Whenever possible, we have written the rules in terms of
conditional_expressions to avoid duplication.
1.b/3 {AI05-0147-1} The rules for conditional_expressions have been
designed as much as possible to work similarly to a parenthesized
expression. The intent is that as much as possible, wherever a
parenthesized expression would be allowed, a
conditional_expression would be allowed, and it should work the
same way.
Syntax
2/3 {AI05-0188-1} conditional_expression ::= if_expression
| case_expression
3/3 {AI05-0147-1} {AI05-0188-1} if_expression ::=
if condition then dependent_expression
{elsif condition then dependent_expression}
[else dependent_expression]
4/3 {AI05-0147-1} condition ::= boolean_expression
5/3 {AI05-0188-1} case_expression ::=
case selecting_expression is
case_expression_alternative {,
case_expression_alternative}
6/3 {AI05-0188-1} case_expression_alternative ::=
when discrete_choice_list =>
dependent_expression
7/3 {AI05-0147-1} Wherever the Syntax Rules allow an expression, a
conditional_expression may be used in place of the expression, so long
as it is immediately surrounded by parentheses.
7.a/3 Discussion: {AI05-0147-1} The syntactic category
conditional_expression appears only as a primary that is
parenthesized. The above rule allows it to additionally be used in
other contexts where it would be directly surrounded by
parentheses.
7.b/3 The grammar makes the following directly legal:
7.c/3 A := (if X then Y else Z); -- parentheses required
A := B + (if X then Y else Z) + C; -- parentheses required
7.d/3 The following procedure calls are syntactically legal; the first
uses the above rule to eliminate the redundant parentheses found
in the second:
7.e/3 P(if X then Y else Z);
P((if X then Y else Z)); -- redundant parentheses
7.f/3 P((if X then Y else Z), Some_Other_Param);
P(Some_Other_Param, (if X then Y else Z));
P(Formal => (if X then Y else Z));
7.g/3 whereas the following are illegal:
7.h/3 P(if X then Y else Z, Some_Other_Param);
P(Some_Other_Param, if X then Y else Z);
P(Formal => if X then Y else Z);
7.i/3 because in these latter cases, the conditional_expression is not
immediately surrounded by parentheses (which means on both sides!).
7.j/3 The English-language rule applies in all places that could
surround an expression with parentheses, including pragma
arguments, type conversion and qualified expression operands, and
array index expressions.
7.k/3 This English-language rule could have been implemented instead by
adding a nonterminal expression_within_parentheses, which would
consist of expressions and conditional_expressions. Then, that
could be used in all of the syntax which could consist of parens
directly around an expression. We did not do that because of the
large amount of change required. A complete grammar is given in
AI05-0147-1.
7.l/3 Implementation Note: {AI05-0147-1} Implementers are cautioned to
consider error detection when implementing the syntax for
conditional_expressions. An if_expression and an if_statement are
very similar syntactically, (as are a case_expression and a
case_statement) and simple mistakes can appear to change one into
the other, potentially causing errors to be moved far away from
their actual location. The absence of end if to terminate an
if_expression (and end case for a case_expression) also may make
error handling harder.
Name Resolution Rules
8/3 {AI05-0147-1} If a conditional_expression is expected to be of a type T,
then each dependent_expression of the conditional_expression is expected to be
of type T. Similarly, if a conditional_expression is expected to be of some
class of types, then each dependent_expression of the conditional_expression
is subject to the same expectation. If a conditional_expression shall resolve
to be of a type T, then each dependent_expression shall resolve to be of type
T.
9/3 {AI05-0147-1} The possible types of a conditional_expression are further
determined as follows:
10/3 * If the conditional_expression is the operand of a type conversion,
the type of the conditional_expression is the target type of the
conversion; otherwise,
10.a/3 Reason: This rule distributes an enclosing type conversion to the
dependent_expressions. This means that
10.b/3 T(if C then A else B)
10.c/3 has the same semantics as
10.d/3 (if C then T(A) else T(B))
11/3 * If all of the dependent_expressions are of the same type, the type of
the conditional_expression is that type; otherwise,
12/3 * If a dependent_expression is of an elementary type, the type of the
conditional_expression shall be covered by that type; otherwise,
12.a/3 Reason: This rule supports the use of numeric literals and
universal expressions within a conditional_expression.
13/3 * If the conditional_expression is expected to be of type T or shall
resolve to type T, then the conditional_expression is of type T.
13.a/3 Ramification: If the type of the conditional_expression cannot be
determined by one of these rules, then Name Resolution has failed
for that expression, even if the dependent_expressions would
resolve individually.
14/3 {AI05-0147-1} A condition is expected to be of any boolean type.
15/3 {AI05-0188-1} The expected type for the selecting_expression and the
discrete_choices are as for case statements (see 5.4).
Legality Rules
16/3 {AI05-0147-1} {AI05-0188-1} All of the dependent_expressions shall be
convertible (see 4.6) to the type of the conditional_expression.
17/3 {AI05-0147-1} {AI05-0188-1} {AI05-0269-1} If the expected type of a
conditional_expression is a specific tagged type, all of the
dependent_expressions of the conditional_expression shall be dynamically tagged, or none
shall be dynamically tagged. In this case, the conditional_expression is
dynamically tagged if all of the dependent_expressions are dynamically tagged,
is tag-indeterminate if all of the dependent_expressions are
tag-indeterminate, and is statically tagged otherwise.
18/3 {AI05-0147-1} {AI05-0262-1} If there is no else dependent_expression, the
if_expression shall be of a boolean type.
19/3 {AI05-0188-1} {AI05-0269-1} All Legality Rules that apply to the
discrete_choices of a case_statement (see 5.4) also apply to the
discrete_choices of a case_expression except within an instance of a generic
unit.
19.a/3 Reason: The exemption for a case expression that occurs in an
instance allows the following example:
19.b/3 generic
with function Int_Func return Integer;
package G is
X : Float := (case Int_Func is
when Integer'First .. -1 => -1.0,
when 0 => 0.0,
when Positive => 1.0);
end G;
19.c/3 function Nat_Func return Natural is (123);
19.d/3 package I is new G (Int_Func => Nat_Func); -- Legal
19.e/3 Note that the Legality Rules still apply in the generic unit
itself; they are just not enforced in an instance of the unit.
Dynamic Semantics
20/3 {AI05-0147-1} {AI05-0188-1} For the evaluation of an if_expression, the
condition specified after if, and any conditions specified after elsif, are
evaluated in succession (treating a final else as elsif True then), until one
evaluates to True or all conditions are evaluated and yield False. If a
condition evaluates to True, the associated dependent_expression is evaluated,
converted to the type of the if_expression, and the resulting value is the
value of the if_expression. Otherwise (when there is no else clause), the
value of the if_expression is True.
20.a/3 Ramification: Else is required unless the if_expression has a
boolean type, so the last sentence can only apply to
if_expressions with a boolean type.
21/3 {AI05-0188-1} For the evaluation of a case_expression, the
selecting_expression is first evaluated. If the value of the selecting_expression is
covered by the discrete_choice_list of some case_expression_alternative, then
the dependent_expression of the case_expression_alternative is evaluated,
converted to the type of the case_expression, and the resulting value is the
value of the case_expression. Otherwise (the value is not covered by any
discrete_choice_list, perhaps due to being outside the base range),
Constraint_Error is raised.
Extensions to Ada 2005
21.a/3 {AI05-0147-1} If expressions and case expressions are new.
4.5.8 Quantified Expressions
0.1/4 {AI12-0158-1} Quantified expressions provide a way to write universally
and existentially quantified predicates over containers and arrays.
Syntax
1/3 {AI05-0176-1} quantified_expression ::= for quantifier
loop_parameter_specification => predicate
| for quantifier iterator_specification => predicate
2/3 quantifier ::= all | some
3/3 predicate ::= boolean_expression
4/3 {AI05-0176-1} Wherever the Syntax Rules allow an expression, a
quantified_expression may be used in place of the expression, so long
as it is immediately surrounded by parentheses.
4.a/3 Discussion: The syntactic category quantified_expression appears
only as a primary that is parenthesized. The above rule allows it
to additionally be used in other contexts where it would be
directly surrounded by parentheses. This is the same rule that is
used for conditional_expressions; see 4.5.7 for a detailed
discussion of the meaning and effects of this rule.
Name Resolution Rules
5/3 {AI05-0176-1} The expected type of a quantified_expression is any Boolean
type. The predicate in a quantified_expression is expected to be of the same
type.
Dynamic Semantics
6/4 {AI05-0176-1} {AI12-0158-1} For the evaluation of a
quantified_expression, the loop_parameter_specification or
iterator_specification is first elaborated. The evaluation of a
quantified_expression then evaluates the predicate for the values of the loop
parameter in the order specified by the loop_parameter_specification (see
5.5) or iterator_specification (see 5.5.2).
7/3 {AI05-0176-1} The value of the quantified_expression is determined as
follows:
8/4 * {AI12-0158-1} If the quantifier is all, the expression is False if the
evaluation of any predicate yields False; evaluation of the
quantified_expression stops at that point. Otherwise (every predicate
has been evaluated and yielded True), the expression is True. Any
exception raised by evaluation of the predicate is propagated.
8.a/3 Ramification: The expression is True if the domain contains no
values.
9/4 * {AI12-0158-1} If the quantifier is some, the expression is True if the
evaluation of any predicate yields True; evaluation of the
quantified_expression stops at that point. Otherwise (every predicate
has been evaluated and yielded False), the expression is False. Any
exception raised by evaluation of the predicate is propagated.
9.a/3 Ramification: The expression is False if the domain contains no
values.
Examples
10/3 {AI05-0176-1} The postcondition for a sorting routine on an array A with
an index subtype T can be written:
11/3 Post => (A'Length < 2 or else
(for all I in A'First .. T'Pred(A'Last) => A (I) <= A (T'Succ (I))))
12/3 {AI05-0176-1} The assertion that a positive number is composite (as
opposed to prime) can be written:
13/3 pragma Assert (for some X in 2 .. N / 2 => N mod X = 0);
Extensions to Ada 2005
13.a/3 {AI05-0176-1} Quantified expressions are new.
Wording Changes from Ada 2012
13.b/4 {AI12-0158-1} Corrigendum: Revised the wording to make it clear
that the semantics is short-circuited, and what the result is when
there are no values for the loop parameter.
4.6 Type Conversions
1/3 {AI05-0299-1} [Explicit type conversions, both value conversions and view
conversions, are allowed between closely related types as defined below. This
subclause also defines rules for value and view conversions to a particular
subtype of a type, both explicit ones and those implicit in other constructs. ]
Syntax
2 type_conversion ::=
subtype_mark(expression)
| subtype_mark(name)
3 The target subtype of a type_conversion is the subtype denoted by the
subtype_mark. The operand of a type_conversion is the expression or name
within the parentheses; its type is the operand type.
4/3 {AI05-0299-1} One type is convertible to a second type if a
type_conversion with the first type as operand type and the second type as
target type is legal according to the rules of this subclause. Two types are
convertible if each is convertible to the other.
4.a Ramification: Note that "convertible" is defined in terms of
legality of the conversion. Whether the conversion would raise an
exception at run time is irrelevant to this definition.
5/2 {8652/0017} {AI95-00184-01} {AI95-00330-01} A type_conversion whose
operand is the name of an object is called a view conversion if both its
target type and operand type are tagged, or if it appears in a call as an
actual parameter of mode out or in out; other type_conversions are called
value conversions.
5.a Ramification: A view conversion to a tagged type can appear in any
context that requires an object name, including in an object
renaming, the prefix of a selected_component, and if the operand
is a variable, on the left side of an assignment_statement. View
conversions to other types only occur as actual parameters.
Allowing view conversions of untagged types in all contexts seemed
to incur an undue implementation burden.
5.b/2 {AI95-00330-01} A type conversion appearing as an in out parameter
in a generic instantiation is not a view conversion; the second
part of the rule only applies to subprogram calls, not
instantiations.
Name Resolution Rules
6 The operand of a type_conversion is expected to be of any type.
6.a Discussion: This replaces the "must be determinable" wording of
Ada 83. This is equivalent to (but hopefully more intuitive than)
saying that the operand of a type_conversion is a "complete
context."
7 The operand of a view conversion is interpreted only as a name; the
operand of a value conversion is interpreted as an expression.
7.a/4 Reason: {AI12-0005-1} This formally resolves the syntactic
ambiguity between the two forms of type_conversion. This matters
as an expression that is a name is evaluated and represents a
value while a name by itself can be an object; we want a view
conversion to be an object.
7.b/4 Ramification: {AI12-0005-1} This wording uses "interpreted as"
rather than "shall be" so that this rule is not used to resolve
overloading; it is solely about evaluation as described above.
Legality Rules
8/2 {AI95-00251-01} In a view conversion for an untagged type, the target type
shall be convertible (back) to the operand type.
8.a/2 Reason: Untagged view conversions appear only as [in] out
parameters. Hence, the reverse conversion must be legal as well.
The forward conversion must be legal even for an out parameter,
because (for example) actual parameters of an access type are
always copied in anyway.
Paragraphs 9 through 20 were reorganized and moved below.
8.b/2 Discussion: {AI95-00251-01} The entire Legality Rules section has
been reorganized to eliminate an unintentional incompatibility
with Ada 83. In rare cases, a type conversion between two types
related by derivation is not allowed by Ada 95, while it is
allowed in Ada 83. The reorganization fixes this. Much of the
wording of the legality section is unchanged, but it is reordered
and reformatted. Because of the limitations of our tools, we had
to delete and replace nearly the entire section. The text of Ada
95 paragraphs 8 through 12, 14, 15, 17, 19, 20, and 24 are
unchanged (just moved); these are now 24.1 through 24.5, 24.12,
24.13, 24.17, 24.19, 24.20, and 8.
21/3 {AI95-00251-01} {AI05-0115-1} If there is a type (other than a root
numeric type) that is an ancestor of both the target type and the operand
type, or both types are class-wide types, then at least one of the following
rules shall apply:
21.1/2 * {AI95-00251-01} The target type shall be untagged; or
22 * The operand type shall be covered by or descended from the target
type; or
22.a Ramification: This is a conversion toward the root, which is
always safe.
23/2 * {AI95-00251-01} The operand type shall be a class-wide type that
covers the target type; or
23.a Ramification: This is a conversion of a class-wide type toward the
leaves, which requires a tag check. See Dynamic Semantics.
23.b/2 {AI95-00251-01} These two rules imply that a conversion from an
ancestor type to a type extension is not permitted, as this would
require specifying the values for additional components, in
general, and changing the tag. An extension_aggregate has to be
used instead, constructing a new value, rather than converting an
existing value. However, a conversion from the class-wide type
rooted at an ancestor type is permitted; such a conversion just
verifies that the operand's tag is a descendant of the target.
23.1/2 * {AI95-00251-01} The operand and target types shall both be
class-wide types and the specific type associated with at least one of
them shall be an interface type.
23.c/2 Ramification: We allow converting any class-wide type T'Class to
or from a class-wide interface type even if the specific type T
does not have an appropriate interface ancestor, because some
extension of T might have the needed ancestor. This is similar to
a conversion of a class-wide type toward the leaves of the tree,
and we need to be consistent. Of course, there is a run-time check
that the actual object has the needed interface.
24/3 {AI95-00251-01} {AI05-0115-1} If there is no type (other than a root
numeric type) that is the ancestor of both the target type and the operand
type, and they are not both class-wide types, one of the following rules shall
apply:
24.1/2 * {AI95-00251-01} If the target type is a numeric type, then the
operand type shall be a numeric type.
24.2/2 * {AI95-00251-01} If the target type is an array type, then the
operand type shall be an array type. Further:
24.3/2 * {AI95-00251-01} The types shall have the same dimensionality;
24.4/2 * {AI95-00251-01} Corresponding index types shall be convertible;
24.5/2 * {AI95-00251-01} The component subtypes shall statically match;
24.6/2 * {AI95-00392-01} If the component types are anonymous access types,
then the accessibility level of the operand type shall not be
statically deeper than that of the target type;
24.b/2 Reason: For unrelated array types, the component types could have
different accessibility, and we had better not allow a conversion
of a local type into a global type, in case the local type points
at local objects. We don't need a check for other types of
components; such components necessarily are for related types, and
either have the same accessibility or (for access discriminants)
cannot be changed so the discriminant check will prevent problems.
24.7/2 * {AI95-00246-01} Neither the target type nor the operand type shall
be limited;
24.c/2 Reason: We cannot allow conversions between unrelated limited
types, as they may have different representations, and (since the
types are limited), a copy cannot be made to reconcile the
representations.
24.8/2 * {AI95-00251-01} {AI95-00363-01} If the target type of a view
conversion has aliased components, then so shall the operand type;
and
24.d/2 Reason: {AI95-00363-01} We cannot allow a view conversion from an
object with unaliased components to an object with aliased
components, because that would effectively allow pointers to
unaliased components. This rule was missing from Ada 95.
24.9/2 * {AI95-00246-01} {AI95-00251-01} The operand type of a view
conversion shall not have a tagged, private, or volatile
subcomponent.
24.e/2 Reason: {AI95-00246-01} We cannot allow view conversions between
unrelated might-be-by-reference types, as they may have different
representations, and a copy cannot be made to reconcile the
representations.
24.f/2 Ramification: These rules only apply to unrelated array
conversions; different (weaker) rules apply to conversions between
related types.
24.10/2 * {AI95-00230-01} If the target type is universal_access, then the
operand type shall be an access type.
24.g/2 Discussion: Such a conversion cannot be written explicitly, of
course, but it can be implicit (see below).
24.11/2 * {AI95-00230-01} {AI95-00251-01} If the target type is a general
access-to-object type, then the operand type shall be universal_-
access or an access-to-object type. Further, if the operand type is
not universal_access:
24.h/2 Discussion: The Legality Rules and Dynamic Semantics are worded so
that a type_conversion T(X) (where T is an access type) is
(almost) equivalent to the attribute_reference X.all'Access, where
the result is of type T. The only difference is that the
type_conversion accepts a null value, whereas the
attribute_reference would raise Constraint_Error.
24.12/2 * {AI95-00251-01} If the target type is an access-to-variable type,
then the operand type shall be an access-to-variable type;
24.i/2 Ramification: If the target type is an access-to-constant type,
then the operand type can be access-to-constant or
access-to-variable.
24.13/2 * {AI95-00251-01} If the target designated type is tagged, then the
operand designated type shall be convertible to the target
designated type;
24.14/2 * {AI95-00251-01} {AI95-00363-01} If the target designated type is
not tagged, then the designated types shall be the same, and
either:
24.15/2 * {AI95-00363-01} the designated subtypes shall statically
match; or
24.16/2 * {AI95-00363-01} {AI95-00384-01} the designated type shall be
discriminated in its full view and unconstrained in any
partial view, and one of the designated subtypes shall be
unconstrained;
24.j/2 Ramification: {AI95-00363-01} This does not require that types
have a partial view in order to allow the conversion, simply that
any partial view that does exist is unconstrained.
24.k/2 {AI95-00384-01} This allows conversions both ways (either subtype
can be unconstrained); while Ada 95 only allowed the conversion if
the target subtype is unconstrained. We generally want type
conversions to be symmetric; which type is the target shouldn't
matter for legality.
24.l/2 Reason: {AI95-00363-01} If the visible partial view is
constrained, we do not allow conversion between unconstrained and
constrained subtypes. This means that whether the full type had
discriminants is not visible to clients of the partial view.
24.l.1/4 Discussion: {AI12-0095-1} We assume the worst in a generic body
whether or not a formal subtype has a constrained partial view;
specifically, in a generic body a discriminated subtype is
considered to have a constrained partial view if it is a
descendant of an untagged generic formal private or derived type
(see 12.5.1 for the formal definition of this rule).
24.m/2 Reason: These rules are designed to ensure that aliased array
objects only need "dope" if their nominal subtype is
unconstrained, but they can always have dope if required by the
run-time model (since no sliding is permitted as part of access
type conversion). By contrast, aliased discriminated objects will
always need their discriminants stored with them, even if
nominally constrained. (Here, we are assuming an implementation
that represents an access value as a single pointer.)
24.17/4 * {AI95-00251-01} {AI05-0148-1} {AI05-0248-1} {AI12-0027-1} The
accessibility level of the operand type shall not be statically
deeper than that of the target type, unless the target type is an
anonymous access type of a stand-alone object. If the target type
is that of such a stand-alone object, the accessibility level of
the operand type shall not be statically deeper than that of the
declaration of the stand-alone object.
24.n/3 Ramification: {AI05-0148-1} The access parameter case is handled
by a run-time check. Run-time checks are also done in instance
bodies, and for stand-alone objects of anonymous access types.
24.n.1/3 Reason: We prohibit storing accesses to objects deeper than a
stand-alone object of an anonymous access-to-object (even while we
allow storing all other accesses) in order to prevent dangling
accesses.
24.18/2 * {AI95-00230-01} If the target type is a pool-specific
access-to-object type, then the operand type shall be
universal_access.
24.o/2 Reason: This allows null to be converted to pool-specific types.
Without it, null could be converted to general access types but
not pool-specific ones, which would be too inconsistent. Remember
that these rules only apply to unrelated types, so we don't have
to talk about conversions to derived or other related types.
24.19/2 * {AI95-00230-01} {AI95-00251-01} If the target type is an
access-to-subprogram type, then the operand type shall be universal_-
access or an access-to-subprogram type. Further, if the operand type
is not universal_access:
24.20/3 * {AI95-00251-01} {AI05-0239-1} The designated profiles shall be
subtype conformant.
24.21/4 * {AI95-00251-01} {AI12-0027-1} The accessibility level of the
operand type shall not be statically deeper than that of the
target type. If the operand type is declared within a generic
body, the target type shall be declared within the generic body.
24.p/2 Reason: The reason it is illegal to convert from an
access-to-subprogram type declared in a generic body to one
declared outside that body is that in an implementation that
shares generic bodies, procedures declared inside the generic need
to have a different calling convention - they need an extra
parameter pointing to the data declared in the current instance.
For procedures declared in the spec, that's OK, because the
compiler can know about them at compile time of the instantiation.
24.22/4 {AI12-0027-1} In addition to the places where Legality Rules normally
apply (see 12.3), these rules apply also in the private part of an instance of
a generic unit.
24.q/4 Discussion: This applies to all of the Legality Rules in this
section. It won't matter for the majority of these rules, but in
any case that it does, we want to apply the same recheck in the
private part. (Ada got the default wrong for these, as there is
only one known case where we don't want to recheck in the private
part, see derivations without record extensions in 3.4.)
Static Semantics
25 A type_conversion that is a value conversion denotes the value that is the
result of converting the value of the operand to the target subtype.
26/3 {AI05-0264-1} A type_conversion that is a view conversion denotes a view
of the object denoted by the operand. This view is a variable of the target
type if the operand denotes a variable; otherwise, it is a constant of the
target type.
27 The nominal subtype of a type_conversion is its target subtype.
Dynamic Semantics
28 For the evaluation of a type_conversion that is a value conversion, the
operand is evaluated, and then the value of the operand is converted to a
corresponding value of the target type, if any. If there is no value of the
target type that corresponds to the operand value, Constraint_Error is
raised[; this can only happen on conversion to a modular type, and only when
the operand value is outside the base range of the modular type.] Additional
rules follow:
29 * Numeric Type Conversion
30 * If the target and the operand types are both integer types, then
the result is the value of the target type that corresponds to the
same mathematical integer as the operand.
31 * If the target type is a decimal fixed point type, then the result
is truncated (toward 0) if the value of the operand is not a
multiple of the small of the target type.
32 * If the target type is some other real type, then the result is
within the accuracy of the target type (see G.2, "
Numeric Performance Requirements", for implementations that
support the Numerics Annex).
32.a Discussion: An integer type might have more bits of precision than
a real type, so on conversion (of a large integer), some precision
might be lost.
33 * If the target type is an integer type and the operand type is
real, the result is rounded to the nearest integer (away from zero
if exactly halfway between two integers).
33.a/2 Discussion: {AI95-00267-01} This was implementation defined in Ada
83. There seems no reason to preserve the nonportability in Ada
95. Round-away-from-zero is the conventional definition of
rounding, and standard Fortran and COBOL both specify rounding
away from zero, so for interoperability, it seems important to
pick this. This is also the most easily "undone" by hand.
Round-to-nearest-even is an alternative, but that is quite
complicated if not supported by the hardware. In any case, this
operation is not usually part of an inner loop, so predictability
and portability are judged most important. A floating point
attribute function Unbiased_Rounding is provided (see A.5.3) for
those applications that require round-to-nearest-even, and a
floating point attribute function Machine_Rounding (also see
A.5.3) is provided for those applications that require the highest
possible performance. "Deterministic" rounding is required for
static conversions to integer as well. See 4.9.
34 * Enumeration Type Conversion
35 * The result is the value of the target type with the same position
number as that of the operand value.
36 * Array Type Conversion
37 * If the target subtype is a constrained array subtype, then a check
is made that the length of each dimension of the value of the
operand equals the length of the corresponding dimension of the
target subtype. The bounds of the result are those of the target
subtype.
38 * If the target subtype is an unconstrained array subtype, then the
bounds of the result are obtained by converting each bound of the
value of the operand to the corresponding index type of the target
type. For each nonnull index range, a check is made that the
bounds of the range belong to the corresponding index subtype.
38.a Discussion: Only nonnull index ranges are checked, per AI83-00313.
39 * In either array case, the value of each component of the result is
that of the matching component of the operand value (see 4.5.2).
39.a Ramification: This applies whether or not the component is
initialized.
39.1/2 * {AI95-00392-01} If the component types of the array types are
anonymous access types, then a check is made that the
accessibility level of the operand type is not deeper than that of
the target type.
39.b/2 Reason: This check is needed for operands that are access
parameters and in instance bodies. Other cases are handled by the
legality rule given previously.
40 * Composite (Non-Array) Type Conversion
41 * The value of each nondiscriminant component of the result is that
of the matching component of the operand value.
41.a Ramification: This applies whether or not the component is
initialized.
42 * [The tag of the result is that of the operand.] If the operand
type is class-wide, a check is made that the tag of the operand
identifies a (specific) type that is covered by or descended from
the target type.
42.a Ramification: This check is certain to succeed if the operand type
is itself covered by or descended from the target type.
42.b Proof: The fact that a type_conversion preserves the tag is stated
officially in 3.9, "Tagged Types and Type Extensions"
43 * For each discriminant of the target type that corresponds to a
discriminant of the operand type, its value is that of the
corresponding discriminant of the operand value; if it corresponds
to more than one discriminant of the operand type, a check is made
that all these discriminants are equal in the operand value.
44 * For each discriminant of the target type that corresponds to a
discriminant that is specified by the derived_type_definition for
some ancestor of the operand type (or if class-wide, some ancestor
of the specific type identified by the tag of the operand), its
value in the result is that specified by the
derived_type_definition.
44.a Ramification: It is a ramification of the rules for the
discriminants of derived types that each discriminant of the
result is covered either by this paragraph or the previous one.
See 3.7.
45 * For each discriminant of the operand type that corresponds to a
discriminant that is specified by the derived_type_definition for
some ancestor of the target type, a check is made that in the
operand value it equals the value specified for it.
46 * For each discriminant of the result, a check is made that its
value belongs to its subtype.
47 * Access Type Conversion
48/3 * {AI05-0148-1} {AI05-0248-1} For an access-to-object type, a check
is made that the accessibility level of the operand type is not
deeper than that of the target type, unless the target type is an
anonymous access type of a stand-alone object. If the target type
is that of such a stand-alone object, a check is made that the
accessibility level of the operand type is not deeper than that of
the declaration of the stand-alone object[; then if the check
succeeds, the accessibility level of the target type becomes that
of the operand type].
48.a/3 Ramification: {AI05-0148-1} This check is needed for operands that
are access parameters, for stand-alone anonymous access objects,
and in instance bodies.
48.b Note that this check can never fail for the implicit conversion to
the anonymous type of an access parameter that is done when
calling a subprogram with an access parameter.
49/2 * {AI95-00230-01} {AI95-00231-01} If the operand value is null, the
result of the conversion is the null value of the target type.
49.a/2 Ramification: A conversion to an anonymous access type happens
implicitly as part of initializing or assigning to an anonymous
access object.
50 * If the operand value is not null, then the result designates the
same object (or subprogram) as is designated by the operand value,
but viewed as being of the target designated subtype (or profile);
any checks associated with evaluating a conversion to the target
designated subtype are performed.
50.a Ramification: The checks are certain to succeed if the target and
operand designated subtypes statically match.
51/4 {AI95-00231-01} {AI05-0153-3} {AI05-0290-1} {AI12-0071-1} After
conversion of the value to the target type, if the target subtype is
constrained, a check is performed that the value satisfies this constraint. If
the target subtype excludes null, then a check is made that the value is not
null. If predicate checks are enabled for the target subtype (see 3.2.4), a
check is performed that the value satisfies the predicates of the target
subtype.
51.a/2 Ramification: {AI95-00231-01} The first check above is a
Range_Check for scalar subtypes, a Discriminant_Check or
Index_Check for access subtypes, and a Discriminant_Check for
discriminated subtypes. The Length_Check for an array conversion
is performed as part of the conversion to the target type. The
check for exclusion of null is an Access_Check.
52 For the evaluation of a view conversion, the operand name is evaluated,
and a new view of the object denoted by the operand is created, whose type is
the target type; if the target type is composite, checks are performed as
above for a value conversion.
53 The properties of this new view are as follows:
54/1 * {8652/0017} {AI95-00184-01} If the target type is composite, the
bounds or discriminants (if any) of the view are as defined above for
a value conversion; each nondiscriminant component of the view denotes
the matching component of the operand object; the subtype of the view
is constrained if either the target subtype or the operand object is
constrained, or if the target subtype is indefinite, or if the operand
type is a descendant of the target type and has discriminants that
were not inherited from the target type;
55 * If the target type is tagged, then an assignment to the view assigns
to the corresponding part of the object denoted by the operand;
otherwise, an assignment to the view assigns to the object, after
converting the assigned value to the subtype of the object (which
might raise Constraint_Error);
56/4 * {AI12-0074-1} Reading the value of the view yields the result of
converting the value of the operand object to the target subtype
(which might raise Constraint_Error), except if the object is of an
elementary type and the view conversion is passed as an out parameter;
in this latter case, the value of the operand object may be used to
initialize the formal parameter without checking against any
constraint of the target subtype (as described more precisely in
6.4.1).
56.a/4 Reason: {AI12-0074-1} This ensures that even an out parameter of
an elementary type is initialized reasonably.
57/4 {AI05-0290-1} {AI12-0096-1} If an Accessibility_Check fails,
Program_Error is raised. If a predicate check fails, the effect is as defined
in subclause 3.2.4, "Subtype Predicates". Any other check associated with a
conversion raises Constraint_Error if it fails.
58 Conversion to a type is the same as conversion to an unconstrained subtype
of the type.
58.a Reason: This definition is needed because the semantics of various
constructs involves converting to a type, whereas an explicit
type_conversion actually converts to a subtype. For example, the
evaluation of a range is defined to convert the values of the
expressions to the type of the range.
58.b Ramification: A conversion to a scalar type, or, equivalently, to
an unconstrained scalar subtype, can raise Constraint_Error if the
value is outside the base range of the type.
58.1/4 {AI12-0027-1} Evaluation of a value conversion of a composite type
either creates a new anonymous object[ (similar to the object created by the
evaluation of an aggregate or a function call)] or yields a new view of the
operand object without creating a new object:
58.2/4 * If the target type is a by-reference type and there is a type that
is an ancestor of both the target type and the operand type then no
new object is created;
58.3/4 * If the target type is an array type having aliased components and
the operand type is an array type having unaliased components, then a
new object is created;
58.4/4 * Otherwise, it is unspecified whether a new object is created.
58.5/4 {AI12-0027-1} If a new object is created, then the initialization of
that object is an assignment operation.
58.b.1/4 Reason: This makes a difference in the case of converting from an
array type with unaliased components to one with aliased
components if the element type has a controlled part.
NOTES
59 20 In addition to explicit type_conversions, type conversions are
performed implicitly in situations where the expected type and the
actual type of a construct differ, as is permitted by the type
resolution rules (see 8.6). For example, an integer literal is of the
type universal_integer, and is implicitly converted when assigned to a
target of some specific integer type. Similarly, an actual parameter
of a specific tagged type is implicitly converted when the
corresponding formal parameter is of a class-wide type.
60 Even when the expected and actual types are the same, implicit subtype
conversions are performed to adjust the array bounds (if any) of an
operand to match the desired target subtype, or to raise
Constraint_Error if the (possibly adjusted) value does not satisfy the
constraints of the target subtype.
61/2 21 {AI95-00230-01} A ramification of the overload resolution rules is
that the operand of an (explicit) type_conversion cannot be an
allocator, an aggregate, a string_literal, a character_literal, or an
attribute_reference for an Access or Unchecked_Access attribute.
Similarly, such an expression enclosed by parentheses is not allowed.
A qualified_expression (see 4.7) can be used instead of such a
type_conversion.
62 22 The constraint of the target subtype has no effect for a
type_conversion of an elementary type passed as an out parameter.
Hence, it is recommended that the first subtype be specified as the
target to minimize confusion (a similar recommendation applies to
renaming and generic formal in out objects).
Examples
63 Examples of numeric type conversion:
64 Real(2*J) -- value is converted to floating point
Integer(1.6) -- value is 2
Integer(-0.4) -- value is 0
65 Example of conversion between derived types:
66 type A_Form is new B_Form;
67 X : A_Form;
Y : B_Form;
68 X := A_Form(Y);
Y := B_Form(X); -- the reverse conversion
69 Examples of conversions between array types:
70 type Sequence is array (Integer range <>) of Integer;
subtype Dozen is Sequence(1 .. 12);
Ledger : array(1 .. 100) of Integer;
71 Sequence(Ledger) -- bounds are those of Ledger
Sequence(Ledger(31 .. 42)) -- bounds are 31 and 42
Dozen(Ledger(31 .. 42)) -- bounds are those of Dozen
Incompatibilities With Ada 83
71.a A character_literal is not allowed as the operand of a
type_conversion, since there are now two character types in
package Standard.
71.b The component subtypes have to statically match in an array
conversion, rather than being checked for matching constraints at
run time.
71.c Because sliding of array bounds is now provided for operations
where it was not in Ada 83, programs that used to raise
Constraint_Error might now continue executing and produce a
reasonable result. This is likely to fix more bugs than it
creates.
Extensions to Ada 83
71.d A type_conversion is considered the name of an object in certain
circumstances (such a type_conversion is called a view
conversion). In particular, as in Ada 83, a type_conversion can
appear as an in out or out actual parameter. In addition, if the
target type is tagged and the operand is the name of an object,
then so is the type_conversion, and it can be used as the prefix
to a selected_component, in an object_renaming_declaration, etc.
71.e We no longer require type-mark conformance between a parameter of
the form of a type conversion, and the corresponding formal
parameter. This had caused some problems for inherited subprograms
(since there isn't really a type-mark for converted formals), as
well as for renamings, formal subprograms, etc. See AI83-00245,
AI83-00318, AI83-00547.
71.f We now specify "deterministic" rounding from real to integer types
when the value of the operand is exactly between two integers
(rounding is away from zero in this case).
71.g "Sliding" of array bounds (which is part of conversion to an array
subtype) is performed in more cases in Ada 95 than in Ada 83.
Sliding is not performed on the operand of a membership test, nor
on the operand of a qualified_expression. It wouldn't make sense
on a membership test, and we wish to retain a connection between
subtype membership and subtype qualification. In general, a
subtype membership test returns True if and only if a
corresponding subtype qualification succeeds without raising an
exception. Other operations that take arrays perform sliding.
Wording Changes from Ada 83
71.h We no longer explicitly list the kinds of things that are not
allowed as the operand of a type_conversion, except in a NOTE.
71.i/3 {AI05-0299-1} The rules in this subclause subsume the rules for
"parameters of the form of a type conversion," and have been
generalized to cover the use of a type conversion as a name.
Incompatibilities With Ada 95
71.j/2 {AI95-00246-01} Amendment Correction: Conversions between
unrelated array types that are limited or (for view conversions)
might be by-reference types are now illegal. The representations
of two such arrays may differ, making the conversions impossible.
We make the check here, because legality should not be based on
representation properties. Such conversions are likely to be rare,
anyway. There is a potential that this change would make a working
program illegal (if the types have the same representation).
71.k/2 {AI95-00363-01} If a discriminated full type has a partial view
(private type) that is constrained, we do not allow conversion
between access-to-unconstrained and access-to-constrained subtypes
designating the type. Ada 95 allowed this conversion and the
declaration of various access subtypes, requiring that the
designated object be constrained and thus making details of the
implementation of the private type visible to the client of the
private type. See 4.8 for more on this topic.
Extensions to Ada 95
71.l/2 {AI95-00230-01} Conversion rules for universal_access were
defined. These allow the use of anonymous access values in
equality tests (see 4.5.2), and also allow the use of null in type
conversions and other contexts that do not provide a single
expected type.
71.m/2 {AI95-00384-01} A type conversion from an access-to-discriminated
and unconstrained object to an access-to-discriminated and
constrained one is allowed. Ada 95 only allowed the reverse
conversion, which was weird and asymmetric. Of course, a
constraint check will be performed for this conversion.
Wording Changes from Ada 95
71.n/2 {8652/0017} {AI95-00184-01} Corrigendum: Wording was added to
ensure that view conversions are constrained, and that a tagged
view conversion has a tagged object. Both rules are needed to
avoid having a way to change the discriminants of a constrained
object.
71.o/2 {8652/0008} {AI95-00168-01} Corrigendum: Wording was added to
ensure that the aliased status of array components cannot change
in a view conversion. This rule was needed to avoid having a way
to change the discriminants of an aliased object. This rule was
repealed later, as Ada 2005 allows changing the discriminants of
an aliased object.
71.p/2 {AI95-00231-01} Wording was added to check subtypes that exclude
null (see 3.10).
71.q/2 {AI95-00251-01} The organization of the legality rules was
changed, both to make it clearer, and to eliminate an
unintentional incompatibility with Ada 83. The old organization
prevented type conversions between some types that were related by
derivation (which Ada 83 always allowed).
71.r/3 {AI95-00330-01} {AI05-0005-1} Clarified that an untagged type
conversion appearing as a generic actual parameter for a generic
in out formal parameter is not a view conversion (and thus is
illegal). This confirms the ACATS tests, so all implementations
already follow this interpretation.
71.s/2 {AI95-00363-01} Rules added by the Corrigendum to eliminate
problems with discriminants of aliased components changing were
removed, as we now generally allow discriminants of aliased
components to be changed.
71.t/2 {AI95-00392-01} Accessibility checks on conversions involving
types with anonymous access components were added. These
components have the level of the type, and conversions can be
between types at different levels, which could cause dangling
access values in the absence of such checks.
Inconsistencies With Ada 2005
71.u/3 {AI05-0148-1} A stand-alone object of an anonymous
access-to-object type now has dynamic accessibility. Normally,
this will make programs legal that were illegal in Ada 2005.
However, it is possible that a program that previously raised
Program_Error now will not. It is very unlikely that an existing
program intentionally depends on the exception being raised; the
change is more likely to fix bugs than introduce them.
Wording Changes from Ada 2005
71.v/3 {AI05-0115-1} Correction: Clarified that a root numeric type is
not considered a common ancestor for a conversion.
71.w/3 {AI05-0153-3} {AI05-0290-1} Added rules so that predicate aspects
(see 3.2.4) are enforced on subtype conversion.
Incompatibilities With Ada 2012
71.x/4 {AI12-0095-1} Corrigendum: Because of a rule added in 12.5.1, the
checks for the legality of an access type conversion in a generic
body were strengthened to use an assume the worst rule. This case
is rather unlikely as a formal private or derived type with
discriminants is required along with a conversion between two
access types whose designated types don't statically match, and
any such programs were at risk having objects disappear while
valid access values still pointed at them.
Wording Changes from Ada 2012
71.y/4 {AI12-0027-1} Corrigendum: Moved the generic boilerplate so that
it covers all Legality Rules in this subclause. This was always
intended, but it is not expected to change anything other than
conversions between unrelated arrays.
71.z/4 {AI12-0027-1} Corrigendum: Added a formal definition of the copy
potentially created by a value conversion of a composite type, so
properties like finalization and accessibility are properly
defined. This model was always intended and expected (else 13.6
would not work), but it was not previously formally defined.
71.aa/4 {AI12-0071-1} Corrigendum: Updated wording of type conversions to
use the new term "satisfies the predicates" (see 3.2.4).
71.bb/4 {AI12-0074-1} Corrigendum: Clarified the wording describing the
effect of view conversions of out parameters such that it is clear
that the detailed effect is defined in 6.4.1, not here.
71.cc/4 {AI12-0096-1} Corrigendum: Updated wording of type conversions so
that the exception raise or other effect of a failed predicate
check is as defined in 3.2.4; we don't want to repeat those rules
here. This doesn't change the behavior for predicate checks
possible in original Ada 2012, only ones using the new aspect
Predicate_Failure.
4.7 Qualified Expressions
1 [A qualified_expression is used to state explicitly the type, and to
verify the subtype, of an operand that is either an expression or an
aggregate. ]
Syntax
2 qualified_expression ::=
subtype_mark'(expression) | subtype_mark'aggregate
Name Resolution Rules
3 The operand (the expression or aggregate) shall resolve to be of the type
determined by the subtype_mark, or a universal type that covers it.
Static Semantics
3.1/3 {AI05-0003-1} [If the operand of a qualified_expression denotes an
object, the qualified_expression denotes a constant view of that object.] The
nominal subtype of a qualified_expression is the subtype denoted by the
subtype_mark.
3.a/3 Proof: {AI05-0003-1} This is stated in 3.3.
Dynamic Semantics
4/4 {AI12-0100-1} The evaluation of a qualified_expression evaluates the
operand (and if of a universal type, converts it to the type determined by the
subtype_mark) and checks that its value belongs to the subtype denoted by the
subtype_mark. The exception Constraint_Error is raised if this check fails.
Furthermore, if predicate checks are enabled for the subtype denoted by the
subtype_mark, a check is performed as defined in subclause 3.2.4, "
Subtype Predicates" that the value satifies the predicates of the subtype.
4.a Ramification: This is one of the few contexts in Ada 95 where
implicit subtype conversion is not performed prior to a constraint
check, and hence no "sliding" of array bounds is provided.
4.a.1/4 {AI12-0100-1} The effect of a failed predicate check is as defined
in 3.2.4; such a check could raise any exception, not just
Constraint_Error or Assertion_Error.
4.b Reason: Implicit subtype conversion is not provided because a
qualified_expression with a constrained target subtype is
essentially an assertion about the subtype of the operand, rather
than a request for conversion. An explicit type_conversion can be
used rather than a qualified_expression if subtype conversion is
desired.
4.c/4 {AI12-0100-1} We do a predicate check here so that a
qualified_expression never allows something that the equivalent
type_conversion would not allow.
NOTES
5 23 When a given context does not uniquely identify an expected type,
a qualified_expression can be used to do so. In particular, if an
overloaded name or aggregate is passed to an overloaded subprogram, it
might be necessary to qualify the operand to resolve its type.
Examples
6 Examples of disambiguating expressions using qualification:
7 type Mask is (Fix, Dec, Exp, Signif);
type Code is (Fix, Cla, Dec, Tnz, Sub);
8 Print (Mask'(Dec)); -- Dec is of type Mask
Print (Code'(Dec)); -- Dec is of type Code
9 for J in Code'(Fix) .. Code'(Dec) loop ... -- qualification needed for either Fix or Dec
for J in Code range Fix .. Dec loop ... -- qualification unnecessary
for J in Code'(Fix) .. Dec loop ... -- qualification unnecessary for Dec
10 Dozen'(1 | 3 | 5 | 7 => 2, others => 0) -- see 4.6
Wording Changes from Ada 2005
10.a/3 {AI05-0003-1} Added a definition of the nominal subtype of a
qualified_expression.
Inconsistencies With Ada 2012
10.b/4 {AI12-0100-1} Corrigendum: A qualified_expression now performs a
predicate check for the named subtype (if it is enabled). Original
Ada 2012 did not include that check (an omission). While this is
formally inconsistent (an exception could be raised when none
would be raised by original Ada 2012), cases when this could be
the case are likely to be rare (the qualified expression would
have to have a stricter subtype than the following usage) and the
check is more likely to detect bugs than be unexpected.
4.8 Allocators
1 [The evaluation of an allocator creates an object and yields an access
value that designates the object. ]
Syntax
2/3 {AI05-0111-3} allocator ::=
new [subpool_specification] subtype_indication
| new [subpool_specification] qualified_expression
2.1/3 {AI05-0111-3} subpool_specification ::= (subpool_handle_name)
2.2/3 {AI05-0104-1} For an allocator with a subtype_indication, the
subtype_indication shall not specify a null_exclusion.
2.a/3 Reason: Such an uninitialized allocator would necessarily raise
Constraint_Error, as the default value is null. Also note that the
syntax does not allow a null_exclusion in an initialized
allocator, so it makes sense to make the uninitialized case
illegal as well.
Name Resolution Rules
3/3 {8652/0010} {AI95-00127-01} {AI05-0111-3} {AI05-0269-1} The expected type
for an allocator shall be a single access-to-object type with designated type
D such that either D covers the type determined by the subtype_mark of the
subtype_indication or qualified_expression, or the expected type is anonymous
and the determined type is D'Class. A subpool_handle_name is expected to be of
any type descended from Subpool_Handle, which is the type used to identify a
subpool, declared in package System.Storage_Pools.Subpools (see 13.11.4).
3.a Discussion: See 8.6, "The Context of Overload Resolution" for the
meaning of "shall be a single ... type whose ..."
3.a.1/1 Ramification: {8652/0010} {AI95-00127-01} An allocator is allowed
as a controlling parameter of a dispatching call (see 3.9.2).
Legality Rules
4 An initialized allocator is an allocator with a qualified_expression. An
uninitialized allocator is one with a subtype_indication. In the
subtype_indication of an uninitialized allocator, a constraint is permitted
only if the subtype_mark denotes an [unconstrained] composite subtype; if
there is no constraint, then the subtype_mark shall denote a definite subtype.
4.a Ramification: For example, ... new S'Class ... (with no
initialization expression) is illegal, but ... new S'Class'(X) ...
is legal, and takes its tag and constraints from the initial value
X. (Note that the former case cannot have a constraint.)
5/2 {AI95-00287-01} If the type of the allocator is an access-to-constant
type, the allocator shall be an initialized allocator.
5.a/2 This paragraph was deleted.{AI95-00287-01}
5.1/3 {AI05-0111-3} If a subpool_specification is given, the type of the
storage pool of the access type shall be a descendant of
Root_Storage_Pool_With_Subpools.
5.2/3 {AI95-00344-01} If the designated type of the type of the allocator is
class-wide, the accessibility level of the type determined by the
subtype_indication or qualified_expression shall not be statically deeper than
that of the type of the allocator.
5.b/2 Reason: This prevents the allocated object from outliving its
type.
5.3/3 {AI95-00416-01} {AI05-0051-1} If the subtype determined by the
subtype_indication or qualified_expression of the allocator has one or more
access discriminants, then the accessibility level of the anonymous access
type of each access discriminant shall not be statically deeper than that of
the type of the allocator (see 3.10.2).
5.c/2 Reason: This prevents the allocated object from outliving its
discriminants.
5.4/3 {AI95-00366-01} {AI05-0052-1} {AI05-0157-1} An allocator shall not be of
an access type for which the Storage_Size has been specified by a static
expression with value zero or is defined by the language to be zero.
5.d/2 Reason: An allocator for an access type that has Storage_Size
specified to be zero is required to raise Storage_Error anyway.
It's better to detect the error at compile-time, as the
allocator might be executed infrequently. This also simplifies the
rules for Pure units, where we do not want to allow any allocators
for library-level access types, as they would represent state.
5.e/3 {AI05-0157-1} We don't need a special rule to cover generic
formals (unlike many other similar Legality Rules). There are only
two cases of interest. For formal access types, the Storage_Size
property is not known in the generic, and surely isn't static, so
this Legality Rule can never apply. For a formal derived type,
this Legality Rule can only be triggered by a parent type having
one of the appropriate properties. But Storage_Size can never be
specified for a derived access type, so it always has the same
value for all child types; additionally, a type derived from a
remote access type (which has Storage_Size defined to be zero) is
also a remote access type. That means that any actual that would
match the formal derived type necessarily has the same
Storage_Size properties, so it is harmless (and preferable) to
check them in the body - they are always known in that case. For
other formal types,allocators are not allowed, so we don't need to
consider them. So we don't need an assume-the-best rule here.
5.5/3 {AI05-0052-1} If the designated type of the type of the allocator is
limited, then the allocator shall not be used to define the value of an access
discriminant, unless the discriminated type is immutably limited (see 7.5).
5.f/3 Reason: Because coextensions work very much like parts, we don't
want users creating limited coextensions for nonlimited types.
This would be similar to extending a nonlimited type with a
limited component. We check this on the allocator. Note that there
is an asymmetry in what types are considered limited; this is
required to preserve privacy. We have to assume that the
designated type might be limited as soon as we see a limited
partial view, but we want to ensure that the containing object is
of a type that is always limited.
5.6/3 {AI05-0052-1} In addition to the places where Legality Rules normally
apply (see 12.3), these rules apply also in the private part of an instance of
a generic unit.
5.g/3 Discussion: This applies to all of the Legality Rules of this
subclause.
Static Semantics
6/3 {AI95-00363-01} {AI05-0041-1} If the designated type of the type of the
allocator is elementary, then the subtype of the created object is the
designated subtype. If the designated type is composite, then the subtype of
the created object is the designated subtype when the designated subtype is
constrained or there is an ancestor of the designated type that has a
constrained partial view; otherwise, the created object is constrained by its
initial value [(even if the designated subtype is unconstrained with
defaults)].
6.a Discussion: See AI83-00331.
6.b/2 Reason: {AI95-00363-01} All objects created by an allocator are
aliased, and most aliased composite objects need to be constrained
so that access subtypes work reasonably. Problematic access
subtypes are prohibited for types with a constrained partial view.
6.c/2 Discussion: {AI95-00363-01} If there is a constrained partial view
of the type, this allows the objects to be unconstrained. This
eliminates privacy breaking (we don't want the objects to act
differently simply because they're allocated). Such a created
object is effectively constrained by its initial value if the
access type is an access-to-constant type, or the designated type
is limited (in all views), but we don't need to state that here.
It is implicit in other rules. Note, however, that a value of an
access-to-constant type can designate a variable object via
'Access or conversion, and the variable object might be assigned
by some other access path, and that assignment might alter the
discriminants.
Dynamic Semantics
7/2 {AI95-00373-01} For the evaluation of an initialized allocator, the
evaluation of the qualified_expression is performed first. An object of the
designated type is created and the value of the qualified_expression is
converted to the designated subtype and assigned to the object.
7.a Ramification: The conversion might raise Constraint_Error.
8 For the evaluation of an uninitialized allocator, the elaboration of the
subtype_indication is performed first. Then:
9/2 * {AI95-00373-01} If the designated type is elementary, an object of the
designated subtype is created and any implicit initial value is
assigned;
10/2 * {8652/0002} {AI95-00171-01} {AI95-00373-01} If the designated type is
composite, an object of the designated type is created with tag, if
any, determined by the subtype_mark of the subtype_indication. This
object is then initialized by default (see 3.3.1) using the
subtype_indication to determine its nominal subtype. A check is made
that the value of the object belongs to the designated subtype.
Constraint_Error is raised if this check fails. This check and the
initialization of the object are performed in an arbitrary order.
10.a Discussion: AI83-00150.
10.1/3 {AI95-00344-01} {AI95-00416-01} {AI05-0024-1} {AI05-0051-1}
{AI05-0234-1} For any allocator, if the designated type of the type of the
allocator is class-wide, then a check is made that the master of the type
determined by the subtype_indication, or by the tag of the value of the
qualified_expression, includes the elaboration of the type of the allocator.
If any part of the subtype determined by the subtype_indication or
qualified_expression of the allocator (or by the tag of the value if the type
of the qualified_expression is class-wide) has one or more access
discriminants, then a check is made that the accessibility level of the
anonymous access type of each access discriminant is not deeper than that of
the type of the allocator. Program_Error is raised if either such check fails.
10.b/3 Reason: {AI95-00344-01} {AI05-0024-1} The master check on
class-wide types prevents the allocated object from outliving its
type. We need the run-time check in instance bodies, or when the
type of the qualified_expression is class-wide (other cases are
statically detected).
10.b.1/3 {AI05-0024-1} We can't use the normal accessibility level "deeper
than" check here because we may have "incomparable" levels if the
appropriate master and the type declaration belong to two
different tasks. This can happen when checking the master of the
tag for an allocator initialized by a parameter passed in to an
accept statement, if the type of the allocator is an access type
declared in the enclosing task body. For example:
10.b.2/3 task body TT is
type Acc_TC is access T'Class;
P : Acc_TC;
begin
accept E(X : T'Class) do
P := new T'Class'(X);
-- Master check on tag of X.
-- Can't use "accessibility levels" since they might be incomparable.
-- Must revert to checking that the master of the type identified by
-- X'tag includes the elaboration of Acc_TC, so it is sure to outlive it.
end E;
10.c/2 {AI95-00416-01} The accessibility check on access discriminants
prevents the allocated object from outliving its discriminants.
10.2/2 {AI95-00280-01} If the object to be created by an allocator has a
controlled or protected part, and the finalization of the collection of the
type of the allocator (see 7.6.1) has started, Program_Error is raised.
10.d/2 Reason: If the object has a controlled or protected part, its
finalization is likely to be nontrivial. If the allocation was
allowed, we could not know whether the finalization would actually
be performed. That would be dangerous to otherwise safe
abstractions, so we mandate a check here. On the other hand, if
the finalization of the object will be trivial, we do not require
(but allow) the check, as no real harm could come from late
allocation.
10.e/2 Discussion: This check can only fail if an allocator is evaluated
in code reached from a Finalize routine for a type declared in the
same master. That's highly unlikely; Finalize routines are much
more likely to be deallocating objects than allocating them.
10.3/2 {AI95-00280-01} If the object to be created by an allocator contains
any tasks, and the master of the type of the allocator is completed, and all
of the dependent tasks of the master are terminated (see 9.3), then
Program_Error is raised.
10.f/2 Reason: A task created after waiting for tasks has finished could
depend on freed data structures, and certainly would never be
awaited.
10.4/3 {AI05-0111-3} If the allocator includes a subpool_handle_name,
Constraint_Error is raised if the subpool handle is null. Program_Error is
raised if the subpool does not belong (see 13.11.4) to the storage pool of the
access type of the allocator.
10.g/3 Implementation Note: This can be implemented by comparing the
result of Pool_of_Subpool to a reference to the storage pool
object. Pool_of_Subpool's parameter is not null, so the check for
null falls out naturally.
10.h/3 Reason: This detects cases where the subpool belongs to another
pool, or to no pool at all. This includes detecting dangling
subpool handles so long as the subpool object (the object
designated by the handle) still exists. (If the subpool object has
been deallocated, execution is erroneous; it is likely that this
check will still detect the problem, but there cannot be a
guarantee.)
11 [If the created object contains any tasks, they are activated (see 9.2).]
Finally, an access value that designates the created object is returned.
Bounded (Run-Time) Errors
11.1/2 {AI95-00280-01} It is a bounded error if the finalization of the
collection of the type (see 7.6.1) of the allocator has started. If the error
is detected, Program_Error is raised. Otherwise, the allocation proceeds
normally.
11.a/2 Discussion: This check is required in some cases; see above.
NOTES
12 24 Allocators cannot create objects of an abstract type. See 3.9.3.
13 25 If any part of the created object is controlled, the
initialization includes calls on corresponding Initialize or Adjust
procedures. See 7.6.
14 26 As explained in 13.11, "Storage Management", the storage for an
object allocated by an allocator comes from a storage pool (possibly
user defined). The exception Storage_Error is raised by an allocator
if there is not enough storage. Instances of Unchecked_Deallocation
may be used to explicitly reclaim storage.
15/3 27 {AI05-0229-1} Implementations are permitted, but not required, to
provide garbage collection.
15.a Ramification: Note that in an allocator, the exception
Constraint_Error can be raised by the evaluation of the
qualified_expression, by the elaboration of the
subtype_indication, or by the initialization.
15.b Discussion: By default, the implementation provides the storage
pool. The user may exercise more control over storage management
by associating a user-defined pool with an access type.
Examples
16 Examples of allocators:
17 new Cell'(0, null, null) -- initialized explicitly, see 3.10.1
new Cell'(Value => 0, Succ => null, Pred => null) -- initialized explicitly
new Cell -- not initialized
18 new Matrix(1 .. 10, 1 .. 20) -- the bounds only are given
new Matrix'(1 .. 10 => (1 .. 20 => 0.0)) -- initialized explicitly
19 new Buffer(100) -- the discriminant only is given
new Buffer'(Size => 80, Pos => 0, Value => (1 .. 80 => 'A')) -- initialized explicitly
20 Expr_Ptr'(new Literal) -- allocator for access-to-class-wide type, see 3.9.1
Expr_Ptr'(new Literal'(Expression with 3.5)) -- initialized explicitly
Incompatibilities With Ada 83
20.a/1 The subtype_indication of an uninitialized allocator may not have
an explicit constraint if the designated type is an access type.
In Ada 83, this was permitted even though the constraint had no
effect on the subtype of the created object.
Extensions to Ada 83
20.b Allocators creating objects of type T are now overloaded on access
types designating T'Class and all class-wide types that cover T.
20.c Implicit array subtype conversion (sliding) is now performed as
part of an initialized allocator.
Wording Changes from Ada 83
20.d We have used a new organization, inspired by the ACID document,
that makes it clearer what is the subtype of the created object,
and what subtype conversions take place.
20.e Discussion of storage management issues, such as garbage
collection and the raising of Storage_Error, has been moved to
13.11, "Storage Management".
Inconsistencies With Ada 95
20.f/2 {AI95-00363-01} If the designated type has a constrained partial
view, the allocated object can be unconstrained. This might cause
the object to take up a different amount of memory, and might
cause the operations to work where they previously would have
raised Constraint_Error. It's unlikely that the latter would
actually matter in a real program (Constraint_Error usually
indicates a bug that would be fixed, not left in a program.) The
former might cause Storage_Error to be raised at a different time
than in an Ada 95 program.
Incompatibilities With Ada 95
20.g/2 {AI95-00366-01} An allocator for an access type that has
Storage_Size specified to be zero is now illegal. Ada 95 allowed
the allocator, but it had to raise Storage_Error if executed. The
primary impact of this change should be to detect bugs.
Extensions to Ada 95
20.h/2 {8652/0010} {AI95-00127-01} Corrigendum: An allocator can be a
controlling parameter of a dispatching call. This was an oversight
in Ada 95.
20.i/2 {AI95-00287-01} Initialized allocators are allowed when the
designated type is limited.
Wording Changes from Ada 95
20.j/2 {8652/0002} {AI95-00171-01} Corrigendum: Clarified the elaboration
of per-object constraints for an uninitialized allocator.
20.k/2 {AI95-00280-01} Program_Error is now raised if the allocator
occurs after the finalization of the collection or the waiting for
tasks. This is not listed as an incompatibility as the Ada 95
behavior was unspecified, and Ada 95 implementations tend to
generate programs that crash in this case.
20.l/2 {AI95-00344-01} Added accessibility checks to class-wide
allocators. These checks could not fail in Ada 95 (as all of the
designated types had to be declared at the same level, so the
access type would necessarily have been at the same level or more
nested than the type of allocated object).
20.m/2 {AI95-00373-01} Revised the description of evaluation of
uninitialized allocators to use "initialized by default" so that
the ordering requirements are the same for all kinds of objects
that are default-initialized.
20.n/2 {AI95-00416-01} Added accessibility checks to access discriminants
of allocators. These checks could not fail in Ada 95 as the
discriminants always have the accessibility of the object.
Incompatibilities With Ada 2005
20.o/3 {AI05-0052-1} Correction: Added a rule to prevent limited
coextensions of nonlimited types. Allowing this would have
far-reaching implementation costs. Because of those costs, it
seems unlikely that any implementation ever supported it properly
and thus it is unlikely that any existing code depends on this
capability.
20.p/3 {AI05-0104-1} Correction: Added a rule to make null_exclusions
illegal for uninitialized allocators, as such an allocator would
always raise Constraint_Error. Programs that depend on the
unconditional raising of a predefined exception should be very
rare.
Extensions to Ada 2005
20.q/3 {AI05-0111-3} Subpool handles (see 13.11.4) can be specified in an
allocator.
Wording Changes from Ada 2005
20.r/3 {AI05-0024-1} Correction: Corrected the master check for tags
since the masters may be for different tasks and thus incomparable.
20.s/3 {AI05-0041-1} Correction: Corrected the rules for when a
designated object is constrained by its initial value so that
types derived from a partial view are handled properly.
20.t/3 {AI05-0051-1} {AI05-0234-1} Correction: Corrected the
accessibility check for access discriminants so that it does not
depend on the designated type (which might not have discriminants
when the allocated type does).
4.9 Static Expressions and Static Subtypes
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 For an expression to be static, it has to be calculable at compile
time.
1.c Only scalar and string expressions are static.
1.d 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 The rules for evaluating static expressions are designed to
maximize portability of static calculations.
2 A static expression is [a scalar or string expression that is] one of the
following:
3 * a numeric_literal;
3.a Ramification: A numeric_literal 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.
4 * a string_literal of a static string subtype;
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 * a name that denotes the declaration of a named number or a static
constant;
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 * an attribute_reference that denotes a scalar value, and whose prefix
denotes a static scalar subtype;
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 An implementation may define the staticness and other properties
of implementation-defined attributes.
8 * an attribute_reference whose prefix statically denotes a statically
constrained array object or array subtype, and whose
attribute_designator is First, Last, or Length, with an optional
dimension;
9 * a type_conversion whose subtype_mark denotes a static scalar subtype,
and whose operand is a static expression;
10 * a qualified_expression whose subtype_mark denotes a static [(scalar or
string)] subtype, and whose operand is a static expression;
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 * {AI05-0158-1} {AI05-0269-1} {AI12-0039-1} a membership test whose
tested_simple_expression is a static expression, and whose
membership_choice_list consists only of membership_choices that are
either static choice_simple_expressions, static ranges, or
subtype_marks that denote a static [(scalar or string)] subtype;
11.a Reason: Clearly, we should allow membership tests in exactly the
same cases where we allow qualified_expressions.
12 * a short-circuit control form both of whose relations are static
expressions;
12.1/3 * {AI05-0147-1} {AI05-0188-1} a conditional_expression all of whose
conditions, selecting_expressions, and dependent_expressions are
static expressions;
13 * a static expression enclosed in parentheses.
13.a Discussion: Informally, we talk about a static value. When we do,
we mean a value specified by a static expression.
13.b Ramification: The language requires a static expression in a
number_declaration, a numeric type definition, a discrete_choice
(sometimes), certain representation items, an
attribute_designator, and when specifying the value of a
discriminant governing a variant_part in a record_aggregate or
extension_aggregate.
14 A name statically denotes an entity if it denotes the entity and:
15 * It is a direct_name, expanded name, or character_literal, and it
denotes a declaration other than a renaming_declaration; or
16 * It is an attribute_reference whose prefix statically denotes some
entity; or
17 * It denotes a renaming_declaration with a name that statically denotes
the renamed entity.
17.a Ramification: Selected_components that are not expanded names and
indexed_components do not statically denote things.
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;
20 * a predefined concatenation operator whose result type is a string type;
21 * an enumeration literal;
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 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 whose value has a length not exceeding the maximum length of a
string_literal in the implementation.
24.a Ramification: A deferred constant is not static; the view
introduced by the corresponding full constant declaration can be
static.
24.b/3 Reason: {AI05-0229-1} The reason for restricting the length of
static string constants is so that compilers don't have to store
giant strings in their symbol tables. Since most string constants
will be initialized from string_literals, the length limit seems
pretty natural. The reason for avoiding nonstring types is also to
save symbol table space. We're trying to keep it cheap and simple
(from the implementer's viewpoint), while still allowing, for
example, the aspect_definition for a Link_Name aspect to contain a
concatenation.
24.c The length we're talking about is the maximum number of characters
in the value represented by a string_literal, not the number of
characters in the source representation; the quotes don't count.
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 {AI95-00263-01} {AI05-0153-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.d generic
F : in out Int10;
procedure G;
26.e procedure G is
begin
case F is
when 1..10 => null;
-- Illegal!
end case;
end G;
26.f X : Integer range 1..20;
procedure I is new G(F => X); -- OK.
26.g 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 {AI95-00311-01} 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 {AI05-0147-1} An expression is statically unevaluated if it is part of:
32.2/3 * {AI05-0147-1} the right operand of a static short-circuit control
form whose value is determined by its left operand; or
32.3/3 * {AI05-0147-1} {AI05-0188-1} a dependent_expression of an
if_expression whose associated condition is static and equals False; or
32.4/3 * {AI05-0147-1} {AI05-0188-1} a condition or dependent_expression of
an if_expression where the condition corresponding to at least one
preceding dependent_expression of the if_expression is static and
equals True; or
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 legal if N and Min are static and N = 0.
32.d/3 Discussion: {AI05-0147-1} {AI05-0188-1} 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 * {AI05-0188-1} {AI05-0269-1} a dependent_expression of a
case_expression whose selecting_expression is static and whose value
is not covered by the corresponding discrete_choice_list; or
32.6/4 * {AI05-0158-1} {AI12-0039-1} a choice_simple_expression (or a
simple_expression of a range that occurs as a membership_choice of a
membership_choice_list) of a static membership test that is preceded
in the enclosing membership_choice_list by another item whose
individual membership test (see 4.5.2) statically yields True.
33/3 {AI05-0147-1} 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 * {AI05-0262-1} 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: {AI05-0262-1} 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 * {AI95-00269-01} 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: {AI95-00269-01} 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 * {AI95-00269-01} 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: {AI95-00269-01} The small is not known for a generic
formal type, so we have to exclude formal types from this check.
37/2 {AI95-00269-01} 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 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 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.
Implementation Requirements
38/2 {AI95-00268-01} {AI95-00269-01} 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: {AI95-00268-01} 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 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 {AI95-00269-01} 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 {AI95-00100-01} 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 {AI95-00268-01} 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.
NOTES
39 28 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 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 The following kinds of expressions are never static:
explicit_dereference, indexed_component, slice, null, aggregate,
allocator.
40 29 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
43 Kilo : constant := 1000;
Mega : constant := Kilo*Kilo; -- 1_000_000
Long : constant := Float'Digits*2;
44 Half_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 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 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 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 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 Certain expressions involving string operations (in particular
concatenation and membership tests) are considered static in Ada
95.
44.l 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 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 {AI05-0299-1} This subclause (and 4.5.5, "Multiplying Operators
") subsumes the RM83 section on Universal Expressions.
44.o 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 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 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 {AI95-00268-01} Amendment Correction: 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 {AI95-00263-01} {AI95-00268-01} 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 {AI95-00269-01} 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 {AI95-00311-01} We clarify that the first subtype of a scalar
formal type has a nonstatic, nonnull constraint.
Wording Changes from Ada 2005
44.w/3 {AI05-0147-1} {AI05-0188-1} 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 {AI05-0153-3} Added wording to prevent subtypes that have dynamic
predicates (see 3.2.4) from being static.
44.y/3 {AI05-0158-1} Revised wording for membership tests to allow for
the new possibilities allowed by the membership_choice_list.
4.9.1 Statically Matching Constraints and Subtypes
Static Semantics
1/2 {AI95-00311-01} A constraint statically matches another constraint if:
1.1/2 * both are null constraints;
1.2/2 * both are static and have equal corresponding bounds or discriminant
values;
1.3/2 * both are nonstatic and result from the same elaboration of a
constraint of a subtype_indication or the same evaluation of a range
of a discrete_subtype_definition; or
1.4/2 * {AI95-00311-01} both are nonstatic and come from the same
formal_type_declaration.
2/3 {AI95-00231-01} {AI95-00254-01} {AI05-0153-3} 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, 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.
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 {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.
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 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 {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:
6/3 * the constraint of S1 is statically compatible with S2, and
7/3 * {AI05-0086-1} 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 * {AI05-0290-1} {AI12-0071-1} 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 This subclause is new to Ada 95.
Wording Changes from Ada 95
10.b/2 {AI95-00231-01} {AI95-00254-01} Added static matching rules for
null exclusions and anonymous access-to-subprogram types; both of
these are new.
10.c/2 {AI95-00311-01} We clarify that the constraint of the first
subtype of a scalar formal type statically matches itself.
Incompatibilities With Ada 2005
10.d/3 {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
10.e/3 {AI05-0153-3} {AI05-0290-1} Modified static matching and static
compatibility to take predicate aspects (see 3.2.4) into account.
Wording Changes from Ada 2012
10.f/4 {AI12-0071-1} Corrigendum: Updated wording of static compatibility
to use the new term "satisfies the predicates" (see 3.2.4).
Generated by dwww version 1.15 on Fri May 24 06:56:30 CEST 2024.