Section 4: Names and Expressions
1 [The rules applicable to the different forms of name and expression, and
to their evaluation, are given in this section.]
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 name ::=
direct_name | explicit_dereference
| indexed_component | slice
| selected_component | attribute_reference
| type_conversion | function_call
| character_literal
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/2 [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 {dereference} {expected type (dereference name) [partial]} The name in a
dereference (either an implicit_dereference or an explicit_dereference) is
expected to be of any access type.
Static Semantics
9 {nominal subtype (associated with a dereference) [partial]} 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.
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: {nominal subtype (of a name) [partial]} 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/2 {AI95-00363-01} If an allocator for the access-to-object type T is
one that creates objects that are constrained by their initial
value (see 4.8), the subtype of the dereference is constrained
even if the designated subtype of T is not. We don't want the
effect of the dereference to depend on the designated object. This
matters because general access-to-unconstrained can designate both
allocated objects (which are constrained at birth) and aliased
stack objects (which aren't necessarily constrained). This is a
wording bug that was discovered after the completion of Amendment
1 when it was too late to fix it; we expect that it will be
corrected by an early Ada 2005 AI.
9.d/2 Implementation Note: {AI95-00363-01} 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 {profile (associated with a dereference) [partial]} 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} {evaluation (name) [partial]} 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 {evaluation (name that has a prefix) [partial]} [The evaluation of a
name that has a prefix includes the evaluation of the prefix.]
{evaluation (prefix) [partial]} 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 {evaluation (dereference) [partial]} 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. {Access_Check
[partial]} {check, language-defined (Access_Check)} A check is made that the
value of the name is not the null access value.
{Constraint_Error (raised by failure of run-time check)} 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 {extensions to Ada 83} 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.
4.1.1 Indexed Components
1 [An indexed_component denotes either a component of an array or an entry
in a family of entries. {array indexing: See indexed_component} ]
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 {expected type (indexed_component expression) [partial]} 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).
{nominal subtype (associated with an indexed_component) [partial]} 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 {evaluation (indexed_component) [partial]} 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. {implicit subtype conversion (array index)
[partial]} {Index_Check [partial]} {check, language-defined (Index_Check)} 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 (raised by failure of run-time check)} 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 [{array slice} 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 {expected type (slice discrete_range) [partial]} 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 {evaluation (slice) [partial]} For the evaluation of a slice, the prefix
and the discrete_range are evaluated in an arbitrary order. {Index_Check
[partial]} {check, language-defined (Index_Check)} {null slice} 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 (raised by failure of run-time check)} 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.
{dot selection: See selected_component} ]
Syntax
2 selected_component ::= prefix . selector_name
3 selector_name ::= identifier | character_literal | operator_symbol
Name Resolution Rules
4 {expanded name} 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/1 Reason: The components of a protected object cannot be named
except by an expanded name, even from within the corresponding
protected body. The protected body may not 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/2 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
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.
{prefixed view} {prefix (of a prefixed view)}
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 {evaluation (selected_component) [partial]} The evaluation of a
selected_component includes the evaluation of the prefix.
15 {Discriminant_Check [partial]}
{check, language-defined (Discriminant_Check)} 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. {Constraint_Error (raised by failure of run-time check)}
{Constraint_Error (raised by failure of run-time check)} 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 {extensions to Ada 83} 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} {extensions to Ada 95} 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". {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);
4.1.4 Attributes
1 {attribute} [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 attribute_designator ::=
identifier[(static_expression)]
| Access | Delta | Digits
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/2 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) was been a procedure; even though the
procedure does not denote an object, the attribute_reference is
still illegal.
7 {expected type (attribute_designator expression) [partial]}
{expected type (range_attribute_designator expression) [partial]} 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 An attribute_reference denotes a value, an object, a subprogram, or some
other kind of program entity.
9.a Ramification: The attributes defined by the language are
summarized in Annex K. Implementations can define additional
attributes.
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 {evaluation (attribute_reference) [partial]}
{evaluation (range_attribute_reference) [partial]} 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 Annex K.
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.
{type conformance (required)}
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 {extensions to Ada 83} 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).
4.2 Literals
1 [{literal} 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.
{constant: See also 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 {expected type (character_literal) [partial]}
{expected profile (character_literal) [partial]} 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 {expected type (string_literal) [partial]} 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 {evaluation (numeric literal) [partial]} {evaluation (null literal)
[partial]} {null access value} {null pointer: See null access value} The
evaluation of a numeric literal, or the literal null, yields the represented
value.
10 {evaluation (string_literal) [partial]} 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 {Range_Check [partial]} {check, language-defined (Range_Check)} 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.
{Constraint_Error (raised by failure of run-time check)} 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 6 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 {incompatibilities with Ada 83} 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 {extensions to Ada 83} 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} {extensions to Ada 95} Null now
has type universal_access, which is similar to other literals.
Null can be used with anonymous access types.
4.3 Aggregates
1 [{aggregate} An aggregate combines component values into a composite value
of an array type, record type, or record extension.]
{literal: See also aggregate}
Syntax
2 aggregate ::= record_aggregate | extension_aggregate
| array_aggregate
Name Resolution Rules
3/2 {AI95-00287-01} {expected type (aggregate) [partial]} 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."
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 {evaluation (aggregate) [partial]} 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.
{assignment operation (during evaluation of an aggregate)} 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 {Discriminant_Check [partial]}
{check, language-defined (Discriminant_Check)} 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 (raised by failure of run-time check)} 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 {extensions to Ada 83} 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} {incompatibilities with Ada 95} 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} {extensions to Ada 95} 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 {named component association} A record_component_association is a
named component association if it has a component_choice_list;
{positional component association} 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 Reason: 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} {expected type (record_aggregate) [partial]} 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 {needed component (record_aggregate record_component_association_list)}
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 {expected type (record_component_association expression) [partial]} The
expected type for the expression of a record_component_association is the type
of the associated component(s);
{associated components (of a record_component_association)} 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.
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 If there are no components needed in a given record_component_association_-
list, then the reserved words null record shall appear rather than a list of
record_component_associations.
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.
16/2 {AI95-00287-01} 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.
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 Discussion: AI83-00244 also requires that the expression shall be
legal for each associated component. This is because even though
two components have the same type, they might have different
subtypes. Therefore, the legality of the expression, particularly
if it is an array aggregate, might differ depending on the
associated component's subtype. However, we have relaxed the rules
on array aggregates slightly for Ada 95, so the staticness of an
applicable index constraint has no effect on the legality of the
array aggregate to which it applies. See 4.3.3. This was the only
case (that we know of) where a subtype provided by context
affected the legality of an expression.
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 If the components of a variant_part are needed, then the value of a
discriminant that governs the variant_part shall be given by a static
expression.
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 {evaluation (record_aggregate) [partial]} The evaluation of a
record_aggregate consists of the evaluation of the
record_component_association_list.
19 {evaluation (record_component_association_list) [partial]} 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. {implicit subtype conversion (expressions in aggregate)
[partial]} 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.
NOTES
21 7 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 {extensions to Ada 83} 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} {extensions to Ada 95} <> 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).
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} {expected type (extension_aggregate) [partial]} The
expected type for an extension_aggregate shall be a single type that is a
record extension. {expected type (extension_aggregate ancestor expression)
[partial]} 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.
Legality Rules
5/2 {AI95-00306-01} 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 derived
from the type of the ancestor_part, through one or more record extensions (and
no private extensions).
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.
Static Semantics
6
{needed component (extension_aggregate record_component_association_list)} 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 {evaluation (extension_aggregate) [partial]} 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 {Discriminant_Check [partial]}
{check, language-defined (Discriminant_Check)} If the type of the
ancestor_part has discriminants that are not inherited by the type of the
extension_aggregate, then, unless the ancestor_part is a subtype_mark that
denotes an unconstrained subtype, a check is made that each discriminant of
the ancestor has the value specified for a corresponding discriminant, 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 (raised by failure of run-time check)} 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.
NOTES
9 8 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 9 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 {extensions to Ada 83} The extension aggregate syntax is new.
Incompatibilities With Ada 95
13.b/2 {AI95-00306-01} {incompatibilities with Ada 95} 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).
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 {n-dimensional array_aggregate} 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). {subaggregate (of an array_aggregate)} 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. {array component expression} 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: {others choice} 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} {expected type (array_aggregate) [partial]} The expected
type for an array_aggregate (that is not a subaggregate) shall be a single
array type. {expected type (array_aggregate component expression) [partial]}
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 {expected type (array_aggregate discrete_choice) [partial]} The expected
type for each discrete_choice in any discrete_choice_list of a
named_array_aggregate is the type of the corresponding index;
{corresponding index (for an array_aggregate)} 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.
{applicable index constraint} [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/2 * {AI95-00318-02} For an explicit_actual_parameter, an
explicit_generic_actual_parameter, the expression of a return
statement, 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, 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 * 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.
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 The discrete_choice_list of an array_component_association is allowed to
have a discrete_choice that is a nonstatic expression or that is a
discrete_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 In a named_array_aggregate with more than one discrete_choice, 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.
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 {evaluation (array_aggregate) [partial]} 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; {implicit subtype conversion (choices of aggregate)
[partial]}
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.
{implicit subtype conversion (expressions of aggregate) [partial]}
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.1/2 {AI95-00287-01} 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 by default as for a stand-alone object of the component subtype
(see 3.3.1).
24 {bounds (of the index range of an array_aggregate)} 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 {Range_Check [partial]} {check, language-defined (Range_Check)} 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 {Index_Check [partial]} {check, language-defined (Index_Check)} For an
array_aggregate with an others choice, a check is made that no expression 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 {Index_Check [partial]} {check, language-defined (Index_Check)} 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 {Constraint_Error (raised by failure of run-time check)} The exception
Constraint_Error is raised if any of the above checks fail.
NOTES
32/2 10 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 {incompatibilities with Ada 83} 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 {extensions to Ada 83} 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} {extensions to Ada 95} <> 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.
4.4 Expressions
1 {expression} 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
other five syntactic categories defined below. {and operator}
{operator (and)} {or operator} {operator (or)} {xor operator} {operator (xor)}
{and then (short-circuit control form)} {or else (short-circuit control form)}
{= operator} {operator (=)} {equal operator} {operator (equal)} {/= operator}
{operator (/=)} {not equal operator} {operator (not equal)} {< operator}
{operator (<)} {less than operator} {operator (less than)} {<= operator}
{operator (<=)} {less than or equal operator} {operator (less than or equal)}
{> operator} {operator (>)} {greater than operator} {operator (greater than)}
{>= operator} {operator (>=)} {greater than or equal operator}
{operator (greater than or equal)} {in (membership test)}
{not in (membership test)} {+ operator} {operator (+)} {plus operator}
{operator (plus)} {- operator} {operator (-)} {minus operator}
{operator (minus)} {& operator} {operator (&)} {ampersand operator}
{operator (ampersand)} {concatenation operator} {operator (concatenation)}
{catenation operator: See concatenation operator} {* operator} {operator (*)}
{multiply operator} {operator (multiply)} {times operator} {operator (times)}
{/ operator} {operator (/)} {divide operator} {operator (divide)}
{mod operator} {operator (mod)} {rem operator} {operator (rem)} {** operator}
{operator (**)} {exponentiation operator} {operator (exponentiation)}
{abs operator} {operator (abs)} {absolute value} {not operator}
{operator (not)}
Syntax
2 expression ::=
relation {and relation} | relation {and then relation}
| relation {or relation} | relation {or else relation}
| relation {xor relation}
3 relation ::=
simple_expression [relational_operator simple_expression]
| simple_expression [not] in range
| simple_expression [not] in 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 primary ::=
numeric_literal | null | string_literal | aggregate
| name | qualified_expression | allocator | (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 {evaluation (primary that is a name) [partial]} The value of a primary
that is a name denoting an object is the value of the object.
Implementation Permissions
11 {Overflow_Check [partial]} {check, language-defined (Overflow_Check)}
{Constraint_Error (raised by failure of run-time check)} 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 Ramification: 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 clause 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 {extensions to Ada 83} 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.
4.5 Operators and Expression Evaluation
1 [{precedence of operators} {operator precedence} 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 {predefined operator} {operator (predefined)} For each form of type
definition, certain of the above operators are predefined; that is, they are
implicitly declared immediately after the type definition. {binary operator}
{operator (binary)} {unary operator} {operator (unary)} 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 [{Constraint_Error (raised by failure of run-time check)} 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 {Constraint_Error (raised by failure of run-time check)} 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 {Constraint_Error (raised by failure of run-time check)} 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 11 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 {short-circuit control form} {and then (short-circuit control form)}
{or else (short-circuit control form)} 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;
{expected type (short-circuit control form relation) [partial]} 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 {logical operator} {operator (logical)} {and operator} {operator (and)}
{or operator} {operator (or)} {xor operator} {operator (xor)} 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: {bit string: See logical operators on boolean arrays}
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.{T (italicized)}
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 {evaluation (short-circuit control form) [partial]} 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 {Length_Check [partial]} {check, language-defined (Length_Check)} 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. {Range_Check [partial]} {check, language-defined (Range_Check)} Also, a
check is made that each component of the result belongs to the component
subtype. {Constraint_Error (raised by failure of run-time check)} 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 12 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 [{relational operator} {operator (relational)}
{comparison operator: See relational operator} {equality operator}
{operator (equality)} The equality operators = (equals) and /= (not equals) are
predefined for nonlimited types. {ordering operator} {operator (ordering)} The
other relational_operators are the ordering operators < (less than), <= (less
than or equal), > (greater than), and >= (greater than or equal).
{= operator} {operator (=)} {equal operator} {operator (equal)} {/= operator}
{operator (/=)} {not equal operator} {operator (not equal)} {< operator}
{operator (<)} {less than operator} {operator (less than)} {<= operator}
{operator (<=)} {less than or equal operator} {operator (less than or equal)}
{> operator} {operator (>)} {greater than operator} {operator (greater than)}
{>= operator} {operator (>=)} {greater than or equal operator}
{operator (greater than or equal)} {discrete array type} 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 {membership test} {in (membership test)} {not in (membership test)} A
membership test, using in or not in, determines whether or not a value belongs
to a given subtype or range, or has a tag that identifies a type that is
covered by a given type. Membership tests are allowed for all types.]
Name Resolution Rules
3/2 {AI95-00251-01} {expected type (membership test simple_expression)
[partial]} {tested type (of a membership test)} The tested type of a
membership test is the type of the range or the type determined by the
subtype_mark. If the tested type is tagged, then the 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 simple_expression is the tested type.
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/2 {AI95-00251-01} The significance of "is convertible to" is that we
allow the 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.
Legality Rules
4 For a membership test, if the 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.
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/2 * it is declared immediately within the same declaration list as 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 non-primitive 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.
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. {unspecified [partial]} [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 {equality operator (special inheritance rule for tagged types)} For a type
extension, predefined equality is defined in terms of the primitive [(possibly
user-defined)] equals operator of the parent type and of any tagged components
of 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.
15 For a private type, if its full type is tagged, predefined equality is
defined in terms of the primitive equals operator of the full type; if the
full type is untagged, predefined equality for the private type is that of its
full type.
16 {matching components} 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 * Otherwise, the result is defined in terms of the primitive equals
operator for any matching tagged components, and the predefined equals
for any matching untagged components.
24.a Reason: This asymmetry between tagged and untagged components is
necessary to preserve upward compatibility and corresponds with
the corresponding situation with generics, where the predefined
operations "reemerge" in a generic for untagged types, but do not
for tagged 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 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 tagged
components, 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/2 For a component with a tagged 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/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.{Unspecified [partial]}
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 {lexicographic order} 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).
27 {evaluation (membership test) [partial]} For the evaluation of a
membership test, the simple_expression and the range (if any) are evaluated in
an arbitrary order.
28 A membership test using in yields the result True if:
29 * The tested type is scalar, and the value of the simple_expression
belongs to the given range, or the range of the named subtype; or
29.a Ramification: The scalar membership test only does a range 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/2 * {AI95-00231-01} The tested type is not scalar, and the value of the
simple_expression satisfies any constraints of the named subtype, and:
30.1/2 * {AI95-00231-01} if the type of the simple_expression is
class-wide, the value has a tag that identifies a type covered by
the tested type;
30.a Ramification: Note that the tag is not checked if the
simple_expression is of a specific type.
30.2/2 * {AI95-00231-01} if the tested type is an access type and the named
subtype excludes null, the value of the simple_expression is not
null.
31 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.
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/1 Ramification: If any language-defined types are implemented with a
user-defined "=" operator, then either the full type must be
tagged, or the compiler must use "magic" to implement equality for
this type. A normal user-defined "=" operator for an untagged type
does not meet this requirement.
NOTES
33/2 This paragraph was deleted.{AI95-00230-01}
34 13 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 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 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)
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 {extensions to Ada 83} 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} {extensions to Ada 95} 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.
4.5.3 Binary Adding Operators
Static Semantics
1 {binary adding operator} {operator (binary adding)} {+ operator}
{operator (+)} {plus operator} {operator (plus)} {- operator} {operator (-)}
{minus operator} {operator (minus)} 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 {& operator} {operator (&)} {ampersand operator} {operator (ampersand)}
{concatenation operator} {operator (concatenation)}
{catenation operator: See concatenation operator} 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 {evaluation (concatenation) [partial]} 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.]
{Index_Check [partial]} {check, language-defined (Index_Check)} 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 (raised by failure of run-time check)} 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. {implicit subtype conversion (operand of concatenation)
[partial]}
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 {assignment operation (during evaluation of concatenation)} 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 14 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 {inconsistencies with Ada 83} 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 {extensions to Ada 83} 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 {unary adding operator} {operator (unary adding)} {+ operator}
{operator (+)} {plus operator} {operator (plus)} {- operator} {operator (-)}
{minus operator} {operator (minus)} 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 15 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 {multiplying operator} {operator (multiplying)} {* operator}
{operator (*)} {multiply operator} {operator (multiply)} {times operator}
{operator (times)} {/ operator} {operator (/)} {divide operator}
{operator (divide)} {mod operator} {operator (mod)} {rem operator}
{operator (rem)} 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 The signed integer modulus operator is defined such that the result of A
mod B 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/2 * it is declared immediately within the same declaration list as the
type; 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.
Legality Rules
20/2 This paragraph was deleted.{AI95-00364-01}
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. {unspecified [partial]} ]
22 {Division_Check [partial]} {check, language-defined (Division_Check)}
{Constraint_Error (raised by failure of run-time check)} 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 16 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 17 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} {incompatibilities with Ada 83}
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 {extensions to Ada 83} 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} {incompatibilities with Ada 95} 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.
4.5.6 Highest Precedence Operators
Static Semantics
1 {highest precedence operator} {operator (highest precedence)}
{abs operator} {operator (abs)} {absolute value} 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 {not operator} {operator (not)} {logical operator: See also not operator}
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). {Range_Check [partial]} {check, language-defined (Range_Check)}
{Constraint_Error (raised by failure of run-time check)} 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 {exponentiation operator} {operator (exponentiation)} {** operator}
{operator (**)} 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 {exponent} The right operand of an exponentiation is the exponent. The
expression X**N with the value of the exponent N positive is equivalent to the
expression 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 {Constraint_Error (raised by failure of run-time check)} 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 18 {Range_Check [partial]} {check, language-defined (Range_Check)} 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 (raised by failure of run-time check)}
Constraint_Error is raised if this check fails.
Inconsistencies With Ada 83
13.a.1/1 {8652/0100} {AI95-00018-01} {inconsistencies with Ada 83} 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.
4.6 Type Conversions
1 [Explicit type conversions, both value conversions and view conversions,
are allowed between closely related types as defined below. This clause also
defines rules for value and view conversions to a particular subtype of a
type, both explicit ones and those implicit in other constructs.
{subtype conversion: See type conversion} {type conversion} {conversion}
{cast: See type conversion}
]{subtype conversion: See also implicit subtype conversion}
{type conversion, implicit: See implicit subtype conversion}
Syntax
2 type_conversion ::=
subtype_mark(expression)
| subtype_mark(name)
3 {target subtype (of a type_conversion)} The target subtype of a
type_conversion is the subtype denoted by the subtype_mark.
{operand (of a type_conversion)} The operand of a type_conversion is the
expression or name within the parentheses;
{operand type (of a type_conversion)} its type is the operand type.
4 {convertible} 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 clause. 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} {view conversion}
{conversion (view)} 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;
{value conversion} {conversion (value)} other type_conversions are called value
conversions. {super: See view conversion}
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 {expected type (type_conversion operand) [partial]} 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 Reason: This formally resolves the syntactic ambiguity between the
two forms of type_conversion, not that it really matters.
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/2 {AI95-00251-01} {type conversion (composite (non-array))}
{conversion (composite (non-array))} If there is a 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} {type conversion (enumeration)}
{conversion (enumeration)} 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/2 {AI95-00251-01} If there is no 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} {type conversion (numeric)} {conversion (numeric)}
If the target type is a numeric type, then the operand type shall be a
numeric type.
24.2/2 * {AI95-00251-01} {type conversion (array)} {conversion (array)} 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;
{convertible (required) [partial]}
24.5/2 * {AI95-00251-01} The component subtypes shall statically match;
{statically matching (required) [partial]}
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;
{accessibility rule (type conversion, array components)
[partial]}
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} {type conversion (access)}
{conversion (access)} 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; {convertible (required) [partial]}
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{statically matching (required) [partial]}
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.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/2 * {AI95-00251-01} {accessibility rule (type conversion) [partial]}
The accessibility level of the operand type shall not be
statically deeper than that of the target type.
{generic contract issue [partial]} 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.
24.n/2 Ramification: The access parameter case is handled by a run-time
check. Run-time checks are also done in instance bodies.
24.18/2 * {AI95-00230-01} {type conversion (access)} {conversion (access)}
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} {type conversion (access)}
{conversion (access)} 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/2 * {AI95-00251-01} The designated profiles shall be
subtype-conformant. {subtype conformance (required)}
24.21/2 * {AI95-00251-01} {accessibility rule (type conversion) [partial]}
The accessibility level of the operand type shall not be
statically deeper than that of the target type.
{generic contract issue [partial]} 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. 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.
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 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 {nominal subtype (associated with a type_conversion) [partial]} The
nominal subtype of a type_conversion is its target subtype.
Dynamic Semantics
28 {evaluation (value conversion) [partial]}
{corresponding value (of the target type of a conversion)} {conversion} 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. {Range_Check [partial]}
{check, language-defined (Range_Check)}
{Constraint_Error (raised by failure of run-time check)} 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 * {type conversion (numeric)} {conversion (numeric)} 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 * {accuracy} 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 * {type conversion (enumeration)} {conversion (enumeration)} 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 * {type conversion (array)} {conversion (array)} Array Type Conversion
37 * {Length_Check [partial]} {check, language-defined (Length_Check)}
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 * {Range_Check [partial]} {check, language-defined (Range_Check)} 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. {implicit subtype conversion (array bounds) [partial]} 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. {Accessibility_Check [partial]}
{check, language-defined (Accessibility_Check)}
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 * {type conversion (composite (non-array))}
{conversion (composite (non-array))} 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.] {Tag_Check
[partial]} {check, language-defined (Tag_Check)} 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;
{Discriminant_Check [partial]}
{check, language-defined (Discriminant_Check)} 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 * {Discriminant_Check [partial]}
{check, language-defined (Discriminant_Check)} 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 * {Range_Check [partial]} {check, language-defined (Range_Check)}
For each discriminant of the result, a check is made that its
value belongs to its subtype.
47 * {type conversion (access)} {conversion (access)} Access Type
Conversion
48 * 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. {Accessibility_Check [partial]}
{check, language-defined (Accessibility_Check)}
48.a Ramification: This check is needed for operands that are access
parameters 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/2 {AI95-00231-01} {Range_Check [partial]}
{check, language-defined (Range_Check)} {Discriminant_Check [partial]}
{check, language-defined (Discriminant_Check)} {Index_Check [partial]}
{check, language-defined (Index_Check)} {Access_Check [partial]}
{check, language-defined (Access_Check)} 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.
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 {evaluation (view conversion) [partial]} 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;
{Length_Check [partial]} {check, language-defined (Length_Check)} {Tag_Check
[partial]} {check, language-defined (Tag_Check)} {Discriminant_Check
[partial]} {check, language-defined (Discriminant_Check)} 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);
{implicit subtype conversion (assignment to view conversion)
[partial]}
56 * 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 access type and the
view conversion is passed as an out parameter; in this latter case,
the value of the operand object is used to initialize the formal
parameter without checking against any constraint of the target
subtype (see 6.4.1).
{implicit subtype conversion (reading a view conversion) [partial]}
56.a Reason: This ensures that even an out parameter of an access type
is initialized reasonably.
57 {Program_Error (raised by failure of run-time check)}
{Constraint_Error (raised by failure of run-time check)} If an
Accessibility_Check fails, Program_Error is raised. 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.
NOTES
59 19 {implicit subtype conversion [distributed]} 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 {implicit subtype conversion [distributed]}
{Constraint_Error (raised by failure of run-time check)} 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 20 {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 21 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 {incompatibilities with Ada 83} 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 {extensions to Ada 83} 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 The rules in this clause 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} {incompatibilities with Ada 95} 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} {extensions to Ada 95} 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/2 {AI95-00330-01} 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 intepretation.
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.
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. {type conversion: See also qualified_expression} ]
Syntax
2 qualified_expression ::=
subtype_mark'(expression) | subtype_mark'aggregate
Name Resolution Rules
3 {operand (of a qualified_expression) [partial]} 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.
Dynamic Semantics
4 {evaluation (qualified_expression) [partial]} {Range_Check [partial]}
{check, language-defined (Range_Check)} {Discriminant_Check [partial]}
{check, language-defined (Discriminant_Check)} {Index_Check [partial]}
{check, language-defined (Index_Check)} 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.
{implicit subtype conversion (qualified_expression) [partial]}
{Constraint_Error (raised by failure of run-time check)} The exception
Constraint_Error is raised if this check fails.
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.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.
NOTES
5 22 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
4.8 Allocators
1 [The evaluation of an allocator creates an object and yields an access
value that designates the object. {new: See allocator}
{malloc: See allocator} {heap management: See also allocator} ]
Syntax
2 allocator ::=
new subtype_indication | new qualified_expression
Name Resolution Rules
3/1 {8652/0010} {AI95-00127-01} {expected type (allocator) [partial]} 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.
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 {initialized allocator} An initialized allocator is an allocator with a
qualified_expression. {uninitialized allocator} 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.
{constructor: See initialized allocator}
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/2 {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.2/2 {AI95-00416-01} If the designated subtype of the type of the allocator
has one or more unconstrained access discriminants, then the accessibility
level of the anonymous access type of each access discriminant, as determined
by the subtype_indication or qualified_expression of the allocator, 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.3/2 {AI95-00366-01} 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. {generic contract issue [partial]} 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. This
rule does not apply in the body of a generic unit or within a body declared
within the declarative region of a generic unit, if the type of the allocator
is a descendant of a formal access type declared within the formal part of the
generic unit.
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/2 The last sentence covers the case of children of generics, and
formal access types of formal packages of the generic unit.
Static Semantics
6/2 {AI95-00363-01} 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
a partial view of the designated type that is constrained; otherwise, the
created object is constrained by its initial value [(even if the designated
subtype is unconstrained with defaults)]. {constrained by its initial value
[partial]}
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} {evaluation (allocator) [partial]} For the evaluation of
an initialized allocator, the evaluation of the qualified_expression is
performed first. {evaluation (initialized allocator) [partial]}
{assignment operation (during evaluation of an initialized allocator)} 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.
{implicit subtype conversion (initialization expression of allocator)
[partial]}
7.a Ramification: The conversion might raise Constraint_Error.
8 {evaluation (uninitialized allocator) [partial]} For the evaluation of an
uninitialized allocator, the elaboration of the subtype_indication is
performed first. Then:
9/2 * {AI95-00373-01}
{assignment operation (during evaluation of an uninitialized allocator)
} 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. {Index_Check
[partial]} {check, language-defined (Index_Check)}
{Discriminant_Check [partial]}
{check, language-defined (Discriminant_Check)} A check is made that the
value of the object belongs to the designated subtype.
{Constraint_Error (raised by failure of run-time check)}
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/2 {AI95-00344-01} {AI95-00416-01} For any allocator, if the designated
type of the type of the allocator is class-wide, then a check is made that the
accessibility level of the type determined by the subtype_indication, or by
the tag of the value of the qualified_expression, is not deeper than that of
the type of the allocator. If the designated subtype of the allocator has one
or more unconstrained 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.{Accessibility_Check [partial]}
{check, language-defined (Accessibility_Check)}
{Program_Error (raised by failure of run-time check)}
10.b/2 Reason: {AI95-00344-01} The accessibility 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.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.{Allocation_Check [partial]} {check, language-defined (Allocation_Check)}
{Program_Error (raised by failure of run-time check)}
10.d/2 Reason: If the object has a controlled or protected part, its
finalization is likely to be non-trivial. 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.{Allocation_Check [partial]}
{check, language-defined (Allocation_Check)}
{Program_Error (raised by failure of run-time check)}
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.
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} {bounded error (cause) [partial]} 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 23 Allocators cannot create objects of an abstract type. See 3.9.3.
13 24 If any part of the created object is controlled, the
initialization includes calls on corresponding Initialize or Adjust
procedures. See 7.6.
14 25 As explained in 13.11, "Storage Management", the storage for an
object allocated by an allocator comes from a storage pool (possibly
user defined). {Storage_Error (raised by failure of run-time check)}
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 26 Implementations are permitted, but not required, to provide
garbage collection (see 13.11.3).
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 {incompatibilities with Ada 83} 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 {extensions to Ada 83} 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} {inconsistencies with Ada 95} 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} {incompatibilities with Ada 95} 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} {extensions to Ada 95} 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.
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} Static
means determinable at compile time, using the declared properties or values of
the program entities.] {constant: See also static}
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 {static (expression)} 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 * a membership test whose simple_expression is a static expression, and
whose range is a static range or whose subtype_mark denotes 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;
13 * a static expression enclosed in parentheses.
13.a Discussion: {static (value)} 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 {statically (denote)} 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 {static (function)} 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 {static (constant)} 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 Reason: 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 link name of a pragma Import 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 {static (range)} A static range is a range whose bounds are static
expressions, [or a range_attribute_reference that is equivalent to such a
range.] {static (discrete_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/2 {AI95-00263-01} {static (subtype)} A static subtype is either a static
scalar subtype or a static string subtype. {static (scalar 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.
{static (string 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.
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 {static (constraint)} The different kinds of static constraint are defined
as follows:
28 * A null constraint is always static;
29 * {static (range constraint)} {static (digits constraint)}
{static (delta constraint)} A scalar constraint is static if it has no
range_constraint, or one with a static range;
30 * {static (index constraint)} An index constraint is static if each
discrete_range is static, and each index subtype of the corresponding
array type is static;
31 * {static (discriminant constraint)} 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 {statically (constrained)} 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
33 A static expression is evaluated at compile time except when it is part of
the right operand of a static short-circuit control form whose value is
determined by its left operand. This evaluation is performed exactly, without
performing Overflow_Checks. For a static expression that is evaluated:
34 * The expression is illegal if its evaluation fails a language-defined
check other than Overflow_Check.
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} {generic contract issue [partial]} 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: For a real static expression with a
non-formal type that is not part of a larger static expression
should be rounded the same as the target system.
NOTES
39 27 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 28 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 {extensions to Ada 83} 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 {incompatibilities with Ada 83} 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 This clause (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} {inconsistencies with Ada 95} 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, non-null constraint.
4.9.1 Statically Matching Constraints and Subtypes
Static Semantics
1/2 {AI95-00311-01} {statically matching (for constraints)} 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/2 {AI95-00231-01} {AI95-00254-01} {statically matching (for subtypes)} A
subtype statically matches another subtype of the same type if they have
statically matching constraints, 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 {statically matching (for ranges)} 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 {statically compatible (for a constraint and a scalar subtype)} 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.
{statically compatible (for a constraint and an access or composite 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. {statically compatible (for two subtypes)} One subtype is
statically compatible with a second subtype if the constraint of the first is
statically compatible with the second subtype.
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.
Wording Changes from Ada 83
4.c This subclause is new to Ada 95.
Wording Changes from Ada 95
4.d/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 in Ada 2005.
4.e/2 {AI95-00311-01} We clarify that the constraint of the first
subtype of a scalar formal type statically matches itself.
Generated by dwww version 1.15 on Sat Jun 15 21:15:43 CEST 2024.