4 Names and Expressions
1/3 The rules applicable to the different forms of name and expression, and to
their evaluation, are given in this clause.
4.1 Names
1 Names can denote declared entities, whether declared explicitly or
implicitly (see 3.1). Names can also denote objects or subprograms designated
by access values; the results of type_conversions or function_calls;
subcomponents and slices of objects and values; protected subprograms, single
entries, entry families, and entries in families of entries. Finally, names
can denote attributes of any of the foregoing.
Syntax
2/3 name ::=
direct_name | explicit_dereference
| indexed_component | slice
| selected_component | attribute_reference
| type_conversion | function_call
| character_literal | qualified_expression
| generalized_reference | generalized_indexing
3 direct_name ::= identifier | operator_symbol
4 prefix ::= name | implicit_dereference
5 explicit_dereference ::= name.all
6 implicit_dereference ::= name
7/3 Certain forms of name (indexed_components, selected_components, slices,
and attribute_references) include a prefix that is either itself a name that
denotes some related entity, or an implicit_dereference of an access value
that designates some related entity.
Name Resolution Rules
8 The name in a dereference (either an implicit_dereference or an
explicit_dereference) is expected to be of any access type.
Static Semantics
9/3 If the type of the name in a dereference is some access-to-object type T,
then the dereference denotes a view of an object, the nominal subtype of the
view being the designated subtype of T. If the designated subtype has
unconstrained discriminants, the (actual) subtype of the view is constrained
by the values of the discriminants of the designated object, except when there
is a partial view of the type of the designated subtype that does not have
discriminants, in which case the dereference is not constrained by its
discriminant values.
10 If the type of the name in a dereference is some access-to-subprogram type
S, then the dereference denotes a view of a subprogram, the profile of the
view being the designated profile of S.
Dynamic Semantics
11/2 The evaluation of a name determines the entity denoted by the name. This
evaluation has no other effect for a name that is a direct_name or a
character_literal.
12 The evaluation of a name that has a prefix includes the evaluation of the
prefix. The evaluation of a prefix consists of the evaluation of the name or
the implicit_dereference. The prefix denotes the entity denoted by the name or
the implicit_dereference.
13 The evaluation of a dereference consists of the evaluation of the name and
the determination of the object or subprogram that is designated by the value
of the name. A check is made that the value of the name is not the null access
value. Constraint_Error is raised if this check fails. The dereference denotes
the object or subprogram designated by the value of the name.
Examples
14 Examples of direct names:
15 Pi -- the direct name of a number (see 3.3.2)
Limit -- the direct name of a constant (see 3.3.1)
Count -- the direct name of a scalar variable (see 3.3.1)
Board -- the direct name of an array variable (see 3.6.1)
Matrix -- the direct name of a type (see 3.6)
Random -- the direct name of a function (see 6.1)
Error -- the direct name of an exception (see 11.1)
16 Examples of dereferences:
17 Next_Car.all
-- explicit dereference denoting the object designated by
-- the access variable Next_Car (see 3.10.1)
Next_Car.Owner
-- selected component with implicit dereference;
-- same as Next_Car.all.Owner
4.1.1 Indexed Components
1 An indexed_component denotes either a component of an array or an entry in
a family of entries.
Syntax
2 indexed_component ::= prefix(expression {, expression})
Name Resolution Rules
3 The prefix of an indexed_component with a given number of expressions
shall resolve to denote an array (after any implicit dereference) with the
corresponding number of index positions, or shall resolve to denote an entry
family of a task or protected object (in which case there shall be only one
expression).
4 The expected type for each expression is the corresponding index type.
Static Semantics
5 When the prefix denotes an array, the indexed_component denotes the
component of the array with the specified index value(s). The nominal subtype
of the indexed_component is the component subtype of the array type.
6 When the prefix denotes an entry family, the indexed_component denotes the
individual entry of the entry family with the specified index value.
Dynamic Semantics
7 For the evaluation of an indexed_component, the prefix and the
expressions are evaluated in an arbitrary order. The value of each
expression is converted to the corresponding index type. A check is made that
each index value belongs to the corresponding index range of the array or
entry family denoted by the prefix. Constraint_Error is raised if this check
fails.
Examples
8 Examples of indexed components:
9 My_Schedule(Sat) -- a component of a one-dimensional array
(see 3.6.1)
Page(10) -- a component of a one-dimensional array
(see 3.6)
Board(M, J + 1) -- a component of a two-dimensional array
(see 3.6.1)
Page(10)(20) -- a component of a component
(see 3.6)
Request(Medium) -- an entry in a family of entries
(see 9.1)
Next_Frame(L)(M, N) -- a component of a function call
(see 6.1)
NOTES
10 1 Notes on the examples: Distinct notations are used for components
of multidimensional arrays (such as Board) and arrays of arrays (such
as Page). The components of an array of arrays are arrays and can
therefore be indexed. Thus Page(10)(20) denotes the 20th component of
Page(10). In the last example Next_Frame(L) is a function call
returning an access value that designates a two-dimensional array.
4.1.2 Slices
1 A slice denotes a one-dimensional array formed by a sequence of
consecutive components of a one-dimensional array. A slice of a variable is a
variable; a slice of a constant is a constant; a slice of a value is a value.
Syntax
2 slice ::= prefix(discrete_range)
Name Resolution Rules
3 The prefix of a slice shall resolve to denote a one-dimensional array
(after any implicit dereference).
4 The expected type for the discrete_range of a slice is the index type of
the array type.
Static Semantics
5 A slice denotes a one-dimensional array formed by the sequence of
consecutive components of the array denoted by the prefix, corresponding to
the range of values of the index given by the discrete_range.
6 The type of the slice is that of the prefix. Its bounds are those defined
by the discrete_range.
Dynamic Semantics
7 For the evaluation of a slice, the prefix and the discrete_range are
evaluated in an arbitrary order. If the slice is not a null slice (a slice
where the discrete_range is a null range), then a check is made that the
bounds of the discrete_range belong to the index range of the array denoted by
the prefix. Constraint_Error is raised if this check fails.
NOTES
8 2 A slice is not permitted as the prefix of an Access
attribute_reference, even if the components or the array as a whole
are aliased. See 3.10.2.
9 3 For a one-dimensional array A, the slice A(N .. N) denotes an array
that has only one component; its type is the type of A. On the other
hand, A(N) denotes a component of the array A and has the
corresponding component type.
Examples
10 Examples of slices:
11 Stars(1 .. 15) -- a slice of 15 characters
(see 3.6.3)
Page(10 .. 10 + Size) -- a slice of 1 + Size components
(see 3.6)
Page(L)(A .. B) -- a slice of the array Page(L)
(see 3.6)
Stars(1 .. 0) -- a null slice
(see 3.6.3)
My_Schedule(Weekday) -- bounds given by subtype
(see 3.6.1 and 3.5.1)
Stars(5 .. 15)(K) -- same as Stars(K)
(see 3.6.3)
-- provided that K is in 5 .. 15
4.1.3 Selected Components
1 Selected_components are used to denote components (including
discriminants), entries, entry families, and protected subprograms; they are
also used as expanded names as described below.
Syntax
2 selected_component ::= prefix . selector_name
3 selector_name ::= identifier | character_literal | operator_symbol
Name Resolution Rules
4 A selected_component is called an expanded name if, according to the
visibility rules, at least one possible interpretation of its prefix denotes a
package or an enclosing named construct (directly, not through a
subprogram_renaming_declaration or generic_renaming_declaration).
5 A selected_component that is not an expanded name shall resolve to denote
one of the following:
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.
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.1/2 * A view of a subprogram whose first formal parameter is of a tagged
type or is an access parameter whose designated type is tagged:
9.2/3 The prefix (after any implicit dereference) shall resolve to denote an
object or value of a specific tagged type T or class-wide type
T'Class. The selector_name shall resolve to denote a view of a
subprogram declared immediately within the declarative region in which
an ancestor of the type T is declared. The first formal parameter of
the subprogram shall be of type T, or a class-wide type that covers T,
or an access parameter designating one of these types. The designator
of the subprogram shall not be the same as that of a component of the
tagged type visible at the point of the selected_component. The
subprogram shall not be an implicitly declared primitive operation of
type T that overrides an inherited subprogram implemented by an entry
or protected subprogram visible at the point of the
selected_component. The selected_component denotes a view of this
subprogram that omits the first formal parameter. This view is called
a prefixed view of the subprogram, and the prefix of the
selected_component (after any implicit dereference) is called the
prefix of the prefixed view.
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.
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 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 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.
Dynamic Semantics
14 The evaluation of a selected_component includes the evaluation of the
prefix.
15 For a selected_component that denotes a component of a variant, a check is
made that the values of the discriminants are such that the value or object
denoted by the prefix has this component. The exception Constraint_Error is
raised if this check fails.
Examples
16 Examples of selected components:
17/2 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)
4.1.4 Attributes
1 An attribute is a characteristic of an entity that can be queried via an
attribute_reference or a range_attribute_reference.
Syntax
2 attribute_reference ::= prefix'attribute_designator
3/2 attribute_designator ::=
identifier[(static_expression)]
| Access | Delta | Digits | Mod
4 range_attribute_reference ::= prefix'range_attribute_designator
5 range_attribute_designator ::= Range[(static_expression)]
Name Resolution Rules
6 In an attribute_reference, if the attribute_designator is for an attribute
defined for (at least some) objects of an access type, then the prefix is
never interpreted as an implicit_dereference; otherwise (and for all
range_attribute_references), if the type of the name within the prefix is of
an access type, the prefix is interpreted as an implicit_dereference.
Similarly, if the attribute_designator is for an attribute defined for (at
least some) functions, then the prefix is never interpreted as a parameterless
function_call; otherwise (and for all range_attribute_references), if the
prefix consists of a name that denotes a function, it is interpreted as a
parameterless function_call.
7 The expression, if any, in an attribute_designator or
range_attribute_designator is expected to be of any integer type.
Legality Rules
8 The expression, if any, in an attribute_designator or
range_attribute_designator shall be static.
Static Semantics
9/4 An attribute_reference denotes a value, an object, a subprogram, or some
other kind of program entity. Unless explicitly specified otherwise, for an
attribute_reference that denotes a value or an object, if its type is scalar,
then its nominal subtype is the base subtype of the type; if its type is
tagged, its nominal subtype is the first subtype of the type; otherwise, its
nominal subtype is a subtype of the type without any constraint,
null_exclusion, or predicate. Similarly, unless explicitly specified
otherwise, for an attribute_reference that denotes a function, when its result
type is scalar, its result subtype is the base subtype of the type, when its
result type is tagged, the result subtype is the first subtype of the type,
and when the result type is some other type, the result subtype is a subtype
of the type without any constraint, null_exclusion, or predicate.
10 A range_attribute_reference X'Range(N) is equivalent to the range
X'First(N) .. X'Last(N), except that the prefix is only evaluated once.
Similarly, X'Range is equivalent to X'First .. X'Last, except that the
prefix is only evaluated once.
Dynamic Semantics
11 The evaluation of an attribute_reference (or range_attribute_reference)
consists of the evaluation of the prefix.
Implementation Permissions
12/1 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.
NOTES
13 4 Attributes are defined throughout this International Standard, and
are summarized in K.2.
14/2 5 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.
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)
4.1.5 User-Defined References
Static Semantics
1/3 Given a discriminated type T, the following type-related operational
aspect may be specified:
2/3 Implicit_Dereference
This aspect is specified by a name that denotes an access
discriminant declared for the type T.
3/3 A (view of a) type with a specified Implicit_Dereference aspect is a
reference type. A reference object is an object of a reference type. The
discriminant named by the Implicit_Dereference aspect is the reference
discriminant of the reference type or reference object. A
generalized_reference is a name that identifies a reference object, and
denotes the object or subprogram designated by the reference discriminant of
the reference object.
Syntax
4/3 generalized_reference ::= reference_object_name
Name Resolution Rules
5/3 The expected type for the reference_object_name in a
generalized_reference is any reference type.
Static Semantics
5.1/4 The Implicit_Dereference aspect is nonoverridable (see 13.1.1).
6/3 A generalized_reference denotes a view equivalent to that of a dereference
of the reference discriminant of the reference object.
7/3 Given a reference type T, the Implicit_Dereference aspect is inherited by
descendants of type T if not overridden. If a descendant type constrains the
value of the reference discriminant of T by a new discriminant, that new
discriminant is the reference discriminant of the descendant. If the
descendant type constrains the value of the reference discriminant of T by an
expression other than the name of a new discriminant, a
generalized_reference that identifies an object of the descendant type denotes
the object or subprogram designated by the value of this constraining
expression.
Dynamic Semantics
8/3 The evaluation of a generalized_reference consists of the evaluation of
the reference_object_name and a determination of the object or subprogram
designated by the reference discriminant of the named reference object. A
check is made that the value of the reference discriminant is not the null
access value. Constraint_Error is raised if this check fails. The
generalized_reference denotes the object or subprogram designated by the value
of the reference discriminant of the named reference object.
Examples
9/3 type Barrel is tagged ... -- holds objects of type Element
10/3 type Ref_Element(Data : access Element) is limited private
with Implicit_Dereference => Data;
-- This Ref_Element type is a "reference" type.
-- "Data" is its reference discriminant.
11/3 function Find (B : aliased in out Barrel; Key : String) return Ref_Element;
-- Return a reference to an element of a barrel.
12/3 B: aliased Barrel;
13/3 ...
14/3 Find (B, "grape") := Element'(...); -- Assign through a reference.
15/3 -- This is equivalent to:
Find (B, "grape").Data.all := Element'(...);
4.1.6 User-Defined Indexing
Static Semantics
1/3 Given a tagged type T, the following type-related, operational aspects may
be specified:
2/3 Constant_Indexing
This aspect shall be specified by a name that denotes one or
more functions declared immediately within the same
declaration list in which T is declared. All such functions
shall have at least two parameters, the first of which is of
type T or T'Class, or is an access-to-constant parameter with
designated type T or T'Class.
3/3 Variable_Indexing
This aspect shall be specified by a name that denotes one or
more functions declared immediately within the same
declaration list in which T is declared. All such functions
shall have at least two parameters, the first of which is of
type T or T'Class, or is an access parameter with designated
type T or T'Class. All such functions shall have a return type
that is a reference type (see 4.1.5), whose reference
discriminant is of an access-to-variable type.
4/4 These aspects are inherited by descendants of T (including the class-wide
type T'Class).
5/3 An indexable container type is (a view of) a tagged type with at least one
of the aspects Constant_Indexing or Variable_Indexing specified. An indexable
container object is an object of an indexable container type. A
generalized_indexing is a name that denotes the result of calling a function
named by a Constant_Indexing or Variable_Indexing aspect.
5.1/4 The Constant_Indexing and Variable_Indexing aspects are nonoverridable
(see 13.1.1).
Paragraphs 6 through 9 were deleted.
Syntax
10/3 generalized_indexing ::= indexable_container_object_prefix
actual_parameter_part
Name Resolution Rules
11/3 The expected type for the indexable_container_object_prefix of a
generalized_indexing is any indexable container type.
12/3 If the Constant_Indexing aspect is specified for the type of the
indexable_container_object_prefix of a generalized_indexing, then the
generalized_indexing is interpreted as a constant indexing under the following
circumstances:
13/3 * when the Variable_Indexing aspect is not specified for the type of
the indexable_container_object_prefix;
14/3 * when the indexable_container_object_prefix denotes a constant;
15/3 * when the generalized_indexing is used within a primary where a name
denoting a constant is permitted.
16/3 Otherwise, the generalized_indexing is interpreted as a variable indexing.
17/3 When a generalized_indexing is interpreted as a constant (or variable)
indexing, it is equivalent to a call on a prefixed view of one of the
functions named by the Constant_Indexing (or Variable_Indexing) aspect of the
type of the indexable_container_object_prefix with the given
actual_parameter_part, and with the indexable_container_object_prefix as the
prefix of the prefixed view.
NOTES
18/4 6 The Constant_Indexing and Variable_Indexing aspects cannot be
redefined when inherited for a derived type, but the functions that
they denote can be modified by overriding or overloading.
Examples
19/3 type Indexed_Barrel is tagged ...
with Variable_Indexing => Find;
-- Indexed_Barrel is an indexable container type,
-- Find is the generalized indexing operation.
20/3 function Find (B : aliased in out Indexed_Barrel; Key : String) return Ref_Element;
-- Return a reference to an element of a barrel (see 4.1.5).
21/3 IB: aliased Indexed_Barrel;
22/3 -- All of the following calls are then equivalent:
Find (IB,"pear").Data.all := Element'(...); -- Traditional call
IB.Find ("pear").Data.all := Element'(...); -- Call of prefixed view
IB.Find ("pear") := Element'(...); -- Implicit dereference (see 4.1.5
)
IB ("pear") := Element'(...); -- Implicit indexing and dereference
IB ("pear").Data.all := Element'(...); -- Implicit indexing only
4.2 Literals
1 A literal represents a value literally, that is, by means of notation
suited to its kind. A literal is either a numeric_literal, a
character_literal, the literal null, or a string_literal.
Name Resolution Rules
2/2 This paragraph was deleted.
3 For a name that consists of a character_literal, either its expected type
shall be a single character type, in which case it is interpreted as a
parameterless function_call that yields the corresponding value of the
character type, or its expected profile shall correspond to a parameterless
function with a character result type, in which case it is interpreted as the
name of the corresponding parameterless function declared as part of the
character type's definition (see 3.5.1). In either case, the
character_literal denotes the enumeration_literal_specification.
4 The expected type for a primary that is a string_literal shall be a single
string type.
Legality Rules
5 A character_literal that is a name shall correspond to a
defining_character_literal of the expected type, or of the result type of the
expected profile.
6 For each character of a string_literal with a given expected string type,
there shall be a corresponding defining_character_literal of the component
type of the expected string type.
7/2 This paragraph was deleted.
Static Semantics
8/2 An integer literal is of type universal_integer. A real literal is of type
universal_real. The literal null is of type universal_access.
Dynamic Semantics
9 The evaluation of a numeric literal, or the literal null, yields the
represented value.
10 The evaluation of a string_literal that is a primary yields an array value
containing the value of each character of the sequence of characters of the
string_literal, as defined in 2.6. The bounds of this array value are
determined according to the rules for positional_array_aggregates (see 4.3.3
), except that for a null string literal, the upper bound is the predecessor
of the lower bound.
11 For the evaluation of a string_literal of type T, a check is made that the
value of each character of the string_literal belongs to the component subtype
of T. For the evaluation of a null string literal, a check is made that its
lower bound is greater than the lower bound of the base range of the index
type. The exception Constraint_Error is raised if either of these checks
fails.
NOTES
12 7 Enumeration literals that are identifiers rather than
character_literals follow the normal rules for identifiers when used
in a name (see 4.1 and 4.1.3). Character_literals used as
selector_names follow the normal rules for expanded names (see 4.1.3
).
Examples
13 Examples of literals:
14 3.14159_26536 -- a real literal
1_345 -- an integer literal
'A' -- a character literal
"Some Text" -- a string literal
4.3 Aggregates
1 An aggregate combines component values into a composite value of an array
type, record type, or record extension.
Syntax
2 aggregate ::= record_aggregate | extension_aggregate
| array_aggregate
Name Resolution Rules
3/2 The expected type for an aggregate shall be a single array type, record
type, or record extension.
Legality Rules
4 An aggregate shall not be of a class-wide type.
Dynamic Semantics
5 For the evaluation of an aggregate, an anonymous object is created and
values for the components or ancestor part are obtained (as described in the
subsequent subclause for each kind of the aggregate) and assigned into the
corresponding components or ancestor part of the anonymous object. Obtaining
the values and the assignments occur in an arbitrary order. The value of the
aggregate is the value of this object.
6 If an aggregate is of a tagged type, a check is made that its value
belongs to the first subtype of the type. Constraint_Error is raised if this
check fails.
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 record_component_association ::=
[component_choice_list =>] expression
| component_choice_list => <>
5 component_choice_list ::=
component_selector_name {| component_selector_name}
| others
6 A record_component_association is a named component association if it
has a component_choice_list; otherwise, it is a positional component
association. Any positional component associations shall precede any
named component associations. If there is a named association with a
component_choice_list of others, it shall come last.
7 In the record_component_association_list for a record_aggregate, if
there is only one association, it shall be a named association.
Name Resolution Rules
8/2 The expected type for a record_aggregate shall be a single record type or
record extension.
9 For the record_component_association_list of a record_aggregate, all
components of the composite value defined by the aggregate are needed; for the
association list of an extension_aggregate, only those components not
determined by the ancestor expression or subtype are needed (see 4.3.2). Each
selector_name in a record_component_association shall denote a needed
component (including possibly a discriminant).
10 The expected type for the expression of a record_component_association is
the type of the associated component(s); the associated component(s) are as
follows:
11 * For a positional association, the component (including possibly a
discriminant) in the corresponding relative position (in the
declarative region of the type), counting only the needed components;
12 * For a named association with one or more component_selector_names, the
named component(s);
13 * For a named association with the reserved word others, all needed
components that are not associated with some previous association.
Legality Rules
14 If the type of a record_aggregate is a record extension, then it shall be
a descendant of a record type, through one or more record extensions (and no
private extensions).
15/3 The reserved words null record may appear only if there are no components
needed in a given record_component_association_list.
16/4 Each record_component_association other than an others choice with a <>
shall have at least one associated component, and each needed component shall
be associated with exactly one record_component_association. If a record_-
component_association with an expression has two or more associated
components, all of them shall be of the same type, or all of them shall be of
anonymous access types whose subtypes statically match. In addition,
Legality Rules are enforced separately for each associated component.
17/3 The value of a discriminant that governs a variant_part P shall be given
by a static expression, unless P is nested within a variant V that is not
selected by the discriminant value governing the variant_part enclosing V.
17.1/2 A record_component_association for a discriminant without a
default_expression shall have an expression rather than <>.
Dynamic Semantics
18 The evaluation of a record_aggregate consists of the evaluation of the
record_component_association_list.
19 For the evaluation of a record_component_association_list, any per-object
constraints (see 3.8) for components specified in the association list are
elaborated and any expressions are evaluated and converted to the subtype of
the associated component. Any constraint elaborations and expression
evaluations (and conversions) occur in an arbitrary order, except that the
expression for a discriminant is evaluated (and converted) prior to the
elaboration of any per-object constraint that depends on it, which in turn
occurs prior to the evaluation and conversion of the expression for the
component with the per-object constraint.
19.1/2 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 8 For a record_aggregate with positional associations, expressions
specifying discriminant values appear first since the
known_discriminant_part is given first in the declaration of the type;
they have to be in the same order as in the known_discriminant_part.
Examples
22 Example of a record aggregate with positional associations:
23 (4, July, 1776) -- see 3.8
24 Examples of record aggregates with named associations:
25 (Day => 4, Month => July, Year => 1776)
(Month => July, Day => 4, Year => 1776)
26 (Disk, Closed, Track => 5, Cylinder => 12) -- see 3.8.1
(Unit => Disk, Status => Closed, Cylinder => 9, Track => 1)
27/2 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)
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.
Syntax
2 extension_aggregate ::=
(ancestor_part with record_component_association_list)
3 ancestor_part ::= expression | subtype_mark
Name Resolution Rules
4/2 The expected type for an extension_aggregate shall be a single type that
is a record extension. If the ancestor_part is an expression, it is expected
to be of any tagged type.
Legality Rules
5/3 If the ancestor_part is a subtype_mark, it shall denote a specific tagged
subtype. If the ancestor_part is an expression, it shall not be dynamically
tagged. The type of the extension_aggregate shall be a descendant of the type
of the ancestor_part (the ancestor type), through one or more record
extensions (and no private extensions). If the ancestor_part is a
subtype_mark, the view of the ancestor type from which the type is descended
(see 7.3.1) shall not have unknown discriminants.
5.1/3 If the type of the ancestor_part is limited and at least one component
is needed in the record_component_association_list, then the ancestor_part
shall not be:
5.2/3 * a call to a function with an unconstrained result subtype; nor
5.3/3 * a parenthesized or qualified expression whose operand would violate
this rule; nor
5.4/3 * a conditional_expression having at least one dependent_expression
that would violate this rule.
Static Semantics
6 For the record_component_association_list of an extension_aggregate, the
only components needed are those of the composite value defined by the
aggregate that are not inherited from the type of the ancestor_part, plus any
inherited discriminants if the ancestor_part is a subtype_mark that denotes an
unconstrained subtype.
Dynamic Semantics
7 For the evaluation of an extension_aggregate, the record_component_-
association_list is evaluated. If the ancestor_part is an expression, it is
also evaluated; if the ancestor_part is a subtype_mark, the components of the
value of the aggregate not given by the record_component_association_list are
initialized by default as for an object of the ancestor type. Any implicit
initializations or evaluations are performed in an arbitrary order, except
that the expression for a discriminant is evaluated prior to any other
evaluation or initialization that depends on it.
8/3 If the type of the ancestor_part has discriminants and the ancestor_part
is not a subtype_mark that denotes an unconstrained subtype, then a check is
made that each discriminant determined by the ancestor_part has the value
specified for a corresponding discriminant, if any, either in the record_-
component_association_list, or in the derived_type_definition for some
ancestor of the type of the extension_aggregate. Constraint_Error is raised if
this check fails.
NOTES
9 9 If all components of the value of the extension_aggregate are
determined by the ancestor_part, then the record_component_association_-
list is required to be simply null record.
10 10 If the ancestor_part is a subtype_mark, then its type can be
abstract. If its type is controlled, then as the last step of
evaluating the aggregate, the Initialize procedure of the ancestor
type is called, unless the Initialize procedure is abstract (see 7.6
).
Examples
11 Examples of extension aggregates (for types defined in 3.9.1):
12 Painted_Point'(Point with Red)
(Point'(P) with Paint => Black)
13 (Expression with Left => 1.2, Right => 3.4)
Addition'(Binop with null record)
-- presuming Binop is of type Binary_Operation
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.
Syntax
2 array_aggregate ::=
positional_array_aggregate | named_array_aggregate
3/2 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 array_component_association ::=
discrete_choice_list => expression
| discrete_choice_list => <>
6 An n-dimensional array_aggregate is one that is written as n levels of
nested array_aggregates (or at the bottom level, equivalent string_literals).
For the multidimensional case (n >= 2) the array_aggregates (or equivalent
string_literals) at the n-1 lower levels are called subaggregates of the
enclosing n-dimensional array_aggregate. The expressions of the bottom level
subaggregates (or of the array_aggregate itself if one-dimensional) are called
the array component expressions of the enclosing n-dimensional
array_aggregate.
Name Resolution Rules
7/2 The expected type for an array_aggregate (that is not a subaggregate)
shall be a single array type. The component type of this array type is the
expected type for each array component expression of the array_aggregate.
8 The expected type for each discrete_choice in any discrete_choice_list of
a named_array_aggregate is the type of the corresponding index; the
corresponding index for an array_aggregate that is not a subaggregate is the
first index of its type; for an (n-m)-dimensional subaggregate within an
array_aggregate of an n-dimensional type, the corresponding index is the index
in position m+1.
Legality Rules
9 An array_aggregate of an n-dimensional array type shall be written as an
n-dimensional array_aggregate.
10 An others choice is allowed for an array_aggregate only if an applicable
index constraint applies to the array_aggregate. An applicable index
constraint is a constraint provided by certain contexts where an
array_aggregate is permitted that can be used to determine the bounds of the
array value specified by the aggregate. Each of the following contexts (and
none other) defines an applicable index constraint:
11/4 * For an explicit_actual_parameter, an
explicit_generic_actual_parameter, the expression of a return
statement, the return expression of an expression function, the
initialization expression in an object_declaration, or a default_-
expression (for a parameter or a component), when the nominal subtype
of the corresponding formal parameter, generic formal parameter,
function return object, expression function return object, object, or
component is a constrained array subtype, the applicable index
constraint is the constraint of the subtype;
12 * For the expression of an assignment_statement where the name denotes
an array variable, the applicable index constraint is the constraint
of the array variable;
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;
15/3 * For a parenthesized expression, the applicable index constraint is
that, if any, defined for the expression;
15.1/3 * For a conditional_expression, the applicable index constraint for
each dependent_expression is that, if any, defined for the
conditional_expression.
16 The applicable index constraint applies to an array_aggregate that appears
in such a context, as well as to any subaggregates thereof. In the case of an
explicit_actual_parameter (or default_expression) for a call on a generic
formal subprogram, no applicable index constraint is defined.
17/3 The discrete_choice_list of an array_component_association is allowed to
have a discrete_choice that is a nonstatic choice_expression or that is a
subtype_indication or range that defines a nonstatic or null range, only if it
is the single discrete_choice of its discrete_choice_list, and there is only
one array_component_association in the array_aggregate.
18/3 In a named_array_aggregate where all discrete_choices are static, no two
discrete_choices are allowed to cover the same value (see 3.8.1); if there is
no others choice, the discrete_choices taken together shall exactly cover a
contiguous sequence of values of the corresponding index type.
19 A bottom level subaggregate of a multidimensional array_aggregate of a
given array type is allowed to be a string_literal only if the component type
of the array type is a character type; each character of such a
string_literal shall correspond to a defining_character_literal of the
component type.
Static Semantics
20 A subaggregate that is a string_literal is equivalent to one that is a
positional_array_aggregate of the same length, with each expression being the
character_literal for the corresponding character of the string_literal.
Dynamic Semantics
21 The evaluation of an array_aggregate of a given array type proceeds in two
steps:
22 1. Any discrete_choices of this aggregate and of its subaggregates are
evaluated in an arbitrary order, and converted to the corresponding
index type;
23 2. The array component expressions of the aggregate are evaluated in an
arbitrary order and their values are converted to the component
subtype of the array type; an array component expression is evaluated
once for each associated component.
23.1/4 Each expression in an array_component_association defines the value for
the associated component(s). For an array_component_association with <>, the
associated component(s) are initialized to the Default_Component_Value of the
array type if this aspect has been specified for the array type; otherwise,
they are initialized by default as for a stand-alone object of the component
subtype (see 3.3.1).
24 The bounds of the index range of an array_aggregate (including a
subaggregate) are determined as follows:
25 * For an array_aggregate with an others choice, the bounds are those of
the corresponding index range from the applicable index constraint;
26 * For a positional_array_aggregate (or equivalent string_literal)
without an others choice, the lower bound is that of the corresponding
index range in the applicable index constraint, if defined, or that of
the corresponding index subtype, if not; in either case, the upper
bound is determined from the lower bound and the number of
expressions (or the length of the string_literal);
27 * For a named_array_aggregate without an others choice, the bounds are
determined by the smallest and largest index values covered by any
discrete_choice_list.
28 For an array_aggregate, a check is made that the index range defined by
its bounds is compatible with the corresponding index subtype.
29/3 For an array_aggregate with an others choice, a check is made that no
expression or <> is specified for an index value outside the bounds determined
by the applicable index constraint.
30 For a multidimensional array_aggregate, a check is made that all
subaggregates that correspond to the same index have the same bounds.
31 The exception Constraint_Error is raised if any of the above checks fail.
NOTES
32/3 11 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 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
4.4 Expressions
1/3 An expression is a formula that defines the computation or retrieval of a
value. In this International Standard, the term "expression" refers to a
construct of the syntactic category expression or of any of the following
categories: choice_expression, choice_relation, relation, simple_expression,
term, factor, primary, conditional_expression, quantified_expression.
Syntax
2 expression ::=
relation {and relation} | relation {and then relation}
| relation {or relation} | relation {or else relation}
| relation {xor relation}
2.1/3 choice_expression ::=
choice_relation {and choice_relation}
| choice_relation {or choice_relation}
| choice_relation {xor choice_relation}
| choice_relation {and then choice_relation}
| choice_relation {or else choice_relation}
2.2/3 choice_relation ::=
simple_expression [relational_operator simple_expression]
3/4 relation ::=
simple_expression [relational_operator simple_expression]
| tested_simple_expression [not] in membership_choice_list
| raise_expression
3.1/3 membership_choice_list ::= membership_choice {| membership_choice}
3.2/4 membership_choice ::= choice_simple_expression | range
| subtype_mark
4 simple_expression ::= [unary_adding_operator] term
{binary_adding_operator term}
5 term ::= factor {multiplying_operator factor}
6 factor ::= primary [** primary] | abs primary | not primary
7/3 primary ::=
numeric_literal | null | string_literal | aggregate
| name | allocator | (expression)
| (conditional_expression) | (quantified_expression)
Name Resolution Rules
8 A name used as a primary shall resolve to denote an object or a value.
Static Semantics
9 Each expression has a type; it specifies the computation or retrieval of a
value of that type.
Dynamic Semantics
10 The value of a primary that is a name denoting an object is the value of
the object.
Implementation Permissions
11 For the evaluation of a primary that is a name denoting an object of an
unconstrained numeric subtype, if the value of the object is outside the base
range of its type, the implementation may either raise Constraint_Error or
return the value of the object.
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 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)
4.5 Operators and Expression Evaluation
1 The language defines the following six categories of operators (given in
order of increasing precedence). The corresponding operator_symbols, and only
those, can be used as designators in declarations of functions for
user-defined operators. See 6.6, "Overloading of Operators".
Syntax
2 logical_operator ::= and | or | xor
3 relational_operator ::=
= | /= | < | <= | > | >=
4 binary_adding_operator ::= + | - | &
5 unary_adding_operator ::= + | -
6 multiplying_operator ::= * | / | mod | rem
7 highest_precedence_operator ::= ** | abs | not
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.
9 For each form of type definition, certain of the above operators are
predefined; that is, they are implicitly declared immediately after the type
definition. For each such implicit operator declaration, the parameters are
called Left and Right for binary operators; the single parameter is called
Right for unary operators. An expression of the form X op Y, where op is a
binary operator, is equivalent to a function_call of the form "op"(X, Y). An
expression of the form op Y, where op is a unary operator, is equivalent to a
function_call of the form "op"(Y). The predefined operators and their effects
are described in subclauses 4.5.1 through 4.5.6.
Dynamic Semantics
10 The predefined operations on integer types either yield the mathematically
correct result or raise the exception Constraint_Error. For implementations
that support the Numerics Annex, the predefined operations on real types yield
results whose accuracy is defined in Annex G, or raise the exception
Constraint_Error.
Implementation Requirements
11 The implementation of a predefined operator that delivers a result of an
integer or fixed point type may raise Constraint_Error only if the result is
outside the base range of the result type.
12 The implementation of a predefined operator that delivers a result of a
floating point type may raise Constraint_Error only if the result is outside
the safe range of the result type.
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.
NOTES
14 12 The two operands of an expression of the form X op Y, where op is
a binary operator, are evaluated in an arbitrary order, as for any
function_call (see 6.4).
Examples
15 Examples of precedence:
16 not Sunny or Warm -- same as (not Sunny) or Warm
X > 4.0 and Y > 0.0 -- same as (X > 4.0) and (Y > 0.0)
17 -4.0*A**2 -- same as -(4.0 * (A**2))
abs(1 + A) + B -- same as (abs (1 + A)) + B
Y**(-3) -- parentheses are necessary
A / B * C -- same as (A/B)*C
A + (B + C) -- evaluate B + C before adding it to A
4.5.1 Logical Operators and Short-circuit Control Forms
Name Resolution Rules
1 An expression consisting of two relations connected by and then or or else
(a short-circuit control form) shall resolve to be of some boolean type; the
expected type for both relations is that same boolean type.
Static Semantics
2 The following logical operators are predefined for every boolean type T,
for every modular type T, and for every one-dimensional array type T whose
component type is a boolean type:
3 function "and"(Left, Right : T) return T
function "or" (Left, Right : T) return T
function "xor"(Left, Right : T) return T
4 For boolean types, the predefined logical operators and, or, and xor
perform the conventional operations of conjunction, inclusive disjunction, and
exclusive disjunction, respectively.
5 For modular types, the predefined logical operators are defined on a
bit-by-bit basis, using the binary representation of the value of the operands
to yield a binary representation for the result, where zero represents False
and one represents True. If this result is outside the base range of the type,
a final subtraction by the modulus is performed to bring the result into the
base range of the type.
6 The logical operators on arrays are performed on a component-by-component
basis on matching components (as for equality - see 4.5.2), using the
predefined logical operator for the component type. The bounds of the
resulting array are those of the left operand.
Dynamic Semantics
7 The short-circuit control forms and then and or else deliver the same
result as the corresponding predefined and and or operators for boolean types,
except that the left operand is always evaluated first, and the right operand
is not evaluated if the value of the left operand determines the result.
8 For the logical operators on arrays, a check is made that for each
component of the left operand there is a matching component of the right
operand, and vice versa. Also, a check is made that each component of the
result belongs to the component subtype. The exception Constraint_Error is
raised if either of the above checks fails.
NOTES
9 13 The conventional meaning of the logical operators is given by the
following truth table:
10 A B (A and B)
(A or B) (A xor B)
True True True
True False
True False False
True True
False True False
True True
False False False
False False
Examples
11 Examples of logical operators:
12 Sunny or Warm
Filter(1 .. 10) and Filter(15 .. 24) -- see 3.6.1
13 Examples of short-circuit control forms:
14 Next_Car.Owner /= null and then Next_Car.Owner.Age > 25 -- see 3.10.1
N = 0 or else A(N) = Hit_Value
4.5.2 Relational Operators and Membership Tests
1 The equality operators = (equals) and /= (not equals) are predefined for
nonlimited types. The other relational_operators are the ordering operators <
(less than), <= (less than or equal), > (greater than), and >= (greater than
or equal). The ordering operators are predefined for scalar types, and for
discrete array types, that is, one-dimensional array types whose components
are of a discrete type.
2/3 A membership test, using in or not in, determines whether or not a value
belongs to any given subtype or range, is equal to any given value, has a tag
that identifies a type that is covered by a given type, or is convertible to
and has an accessibility level appropriate for a given access type. Membership
tests are allowed for all types.
Name Resolution Rules
3/3 The tested type of a membership test is determined by the
membership_choices of the membership_choice_list. Either all
membership_choices of the membership_choice_list shall resolve to the same
type, which is the tested type; or each membership_choice shall be of an
elementary type, and the tested type shall be covered by each of these
elementary types.
3.1/4 If the tested type is tagged, then the tested_simple_expression shall
resolve to be of a type that is convertible (see 4.6) to the tested type; if
untagged, the expected type for the tested_simple_expression is the tested
type. The expected type of a choice_simple_expression in a membership_choice,
and of a simple_expression of a range in a membership_choice, is the tested
type of the membership operation.
Legality Rules
4/4 For a membership test, if the tested_simple_expression is of a tagged
class-wide type, then the tested type shall be (visibly) tagged.
4.1/4 If a membership test includes one or more choice_simple_expressions and
the tested type of the membership test is limited, then the tested type of the
membership test shall have a visible primitive equality operator.
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 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 At least one of the operands of an equality operator for
universal_access shall be of a specific anonymous access type. Unless the
predefined equality operator is identified using an expanded name with
prefix denoting the package Standard, neither operand shall be of an
access-to-object type whose designated type is D or D'Class, where D has a
user-defined primitive equality operator such that:
9.2/2 * its result type is Boolean;
9.3/3 * it is declared immediately within the same declaration list as D or
any partial or incomplete view of D; and
9.4/2 * at least one of its operands is an access parameter with designated
type D.
Legality Rules
9.5/2 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.8/4 If the profile of an explicitly declared primitive equality operator of
an untagged record type is type conformant with that of the corresponding
predefined equality operator, the declaration shall occur before the type is
frozen. In addition to the places where Legality Rules normally apply (see
12.3), this rule applies also in the private part of an instance of a generic
unit.
Dynamic Semantics
10 For discrete types, the predefined relational operators are defined in
terms of corresponding mathematical operations on the position numbers of the
values of the operands.
11 For real types, the predefined relational operators are defined in terms
of the corresponding mathematical operations on the values of the operands,
subject to the accuracy of the type.
12 Two access-to-object values are equal if they designate the same object,
or if both are equal to the null value of the access type.
13 Two access-to-subprogram values are equal if they are the result of the
same evaluation of an Access attribute_reference, or if both are equal to the
null value of the access type. Two access-to-subprogram values are unequal if
they designate different subprograms. It is unspecified whether two access
values that designate the same subprogram but are the result of distinct
evaluations of Access attribute_references are equal or unequal.
14/3 For a type extension, predefined equality is defined in terms of the
primitive (possibly user-defined) equals operator for the parent type and for
any components that have a record type in the extension part, and predefined
equality for any other components not inherited from the parent type.
14.1/3 For a derived type whose parent is an untagged record type, predefined
equality is defined in terms of the primitive (possibly user-defined) equals
operator of the parent type.
15/3 For a private type, if its full type is a record type, predefined
equality is defined in terms of the primitive equals operator of the full
type; otherwise, predefined equality for the private type is that of its full
type.
16 For other composite types, the predefined equality operators (and certain
other predefined operations on composite types - see 4.5.1 and 4.6) are
defined in terms of the corresponding operation on matching components,
defined as follows:
17 * For two composite objects or values of the same non-array type,
matching components are those that correspond to the same
component_declaration or discriminant_specification;
18 * For two one-dimensional arrays of the same type, matching components
are those (if any) whose index values match in the following sense:
the lower bounds of the index ranges are defined to match, and the
successors of matching indices are defined to match;
19 * For two multidimensional arrays of the same type, matching components
are those whose index values match in successive index positions.
20 The analogous definitions apply if the types of the two objects or values
are convertible, rather than being the same.
21 Given the above definition of matching components, the result of the
predefined equals operator for composite types (other than for those composite
types covered earlier) is defined as follows:
22 * If there are no components, the result is defined to be True;
23 * If there are unmatched components, the result is defined to be False;
24/3 * Otherwise, the result is defined in terms of the primitive equals
operator for any matching components that are records, and the
predefined equals for any other matching components.
24.1/3 If the primitive equals operator for an untagged record type is
abstract, then Program_Error is raised at the point of any (implicit) call to
that abstract subprogram.
24.2/1 For any composite type, the order in which "=" is called for components
is unspecified. Furthermore, if the result can be determined before calling
"=" on some components, it is unspecified whether "=" is called on those
components.
25 The predefined "/=" operator gives the complementary result to the
predefined "=" operator.
26/3 For a discrete array type, the predefined ordering operators correspond
to lexicographic order using the predefined order relation of the component
type: A null array is lexicographically less than any array having at least
one component. In the case of nonnull arrays, the left operand is
lexicographically less than the right operand if the first component of the
left operand is less than that of the right; otherwise, the left operand is
lexicographically less than the right operand only if their first components
are equal and the tail of the left operand is lexicographically less than that
of the right (the tail consists of the remaining components beyond the first
and can be null).
26.1/3 An individual membership test is the membership test of a single
membership_choice.
27/4 For the evaluation of a membership test using in whose
membership_choice_list has a single membership_choice, the
tested_simple_expression and the membership_choice are evaluated in an arbitrary
order; the result is the result of the individual membership test for the
membership_choice.
27.1/4 For the evaluation of a membership test using in whose
membership_choice_list has more than one membership_choice, the
tested_simple_expression of the membership test is evaluated first and the result of
the operation is equivalent to that of a sequence consisting of an individual
membership test on each membership_choice combined with the short-circuit
control form or else.
28/3 An individual membership test yields the result True if:
28.1/4 * The membership_choice is a choice_simple_expression, and the
tested_simple_expression is equal to the value of the membership_choice. If
the tested type is a record type or a limited type, the test uses the
primitive equality for the type; otherwise, the test uses predefined
equality.
28.2/4 * The membership_choice is a range and the value of the
tested_simple_expression belongs to the given range.
29/4 * The membership_choice is a subtype_mark, the tested type is scalar,
the value of the tested_simple_expression belongs to the range of the
named subtype, and the value satisfies the predicates of the named
subtype.
30/4 * The membership_choice is a subtype_mark, the tested type is not
scalar, the value of the tested_simple_expression satisfies any
constraints of the named subtype, the value satisfies the predicates
of the named subtype, and:
30.1/4 * if the type of the tested_simple_expression is class-wide, the
value has a tag that identifies a type covered by the tested type;
30.2/4 * if the tested type is an access type and the named subtype
excludes null, the value of the tested_simple_expression is not
null;
30.3/4 * if the tested type is a general access-to-object type, the type of
the tested_simple_expression is convertible to the tested type and
its accessibility level is no deeper than that of the tested type;
further, if the designated type of the tested type is tagged and
the tested_simple_expression is nonnull, the tag of the object
designated by the value of the tested_simple_expression is covered
by the designated type of the tested type.
31/3 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 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.
NOTES
33/2 This paragraph was deleted.
34 14 If a composite type has components that depend on discriminants,
two values of this type have matching components if and only if their
discriminants are equal. Two nonnull arrays have matching components
if and only if the length of each dimension is the same for both.
Examples
35 Examples of expressions involving relational operators and membership
tests:
36 X /= Y
37 "" < "A" and "A" < "Aa" -- True
"Aa" < "B" and "A" < "A " -- True
38/3 My_Car = null -- True if My_Car has been set to null (see 3.10.1
)
My_Car = Your_Car -- True if we both share the same car
My_Car.all = Your_Car.all -- True if the two cars are identical
39/3 N not in 1 .. 10 -- range membership test
Today in Mon .. Fri -- range membership test
Today in Weekday -- subtype membership test (see 3.5.1)
Card in Clubs | Spades -- list membership test (see 3.5.1)
Archive in Disk_Unit -- subtype membership test (see 3.8.1)
Tree.all in Addition'Class -- class membership test (see 3.9.1)
4.5.3 Binary Adding Operators
Static Semantics
1 The binary adding operators + (addition) and - (subtraction) are
predefined for every specific numeric type T with their conventional meaning.
They have the following specifications:
2 function "+"(Left, Right : T) return T
function "-"(Left, Right : T) return T
3 The concatenation operators & are predefined for every nonlimited,
one-dimensional array type T with component type C. They have the following
specifications:
4 function "&"(Left : T; Right : T) return T
function "&"(Left : T; Right : C) return T
function "&"(Left : C; Right : T) return T
function "&"(Left : C; Right : C) return T
Dynamic Semantics
5 For the evaluation of a concatenation with result type T, if both operands
are of type T, the result of the concatenation is a one-dimensional array
whose length is the sum of the lengths of its operands, and whose components
comprise the components of the left operand followed by the components of the
right operand. If the left operand is a null array, the result of the
concatenation is the right operand. Otherwise, the lower bound of the result
is determined as follows:
6 * If the ultimate ancestor of the array type was defined by a
constrained_array_definition, then the lower bound of the result is
that of the index subtype;
7 * If the ultimate ancestor of the array type was defined by an
unconstrained_array_definition, then the lower bound of the result is
that of the left operand.
8 The upper bound is determined by the lower bound and the length. A check
is made that the upper bound of the result of the concatenation belongs to the
range of the index subtype, unless the result is a null array.
Constraint_Error is raised if this check fails.
9 If either operand is of the component type C, the result of the
concatenation is given by the above rules, using in place of such an operand
an array having this operand as its only component (converted to the component
subtype) and having the lower bound of the index subtype of the array type as
its lower bound.
10 The result of a concatenation is defined in terms of an assignment to an
anonymous object, as for any function call (see 6.5).
NOTES
11 15 As for all predefined operators on modular types, the binary
adding operators + and - on modular types include a final reduction
modulo the modulus if the result is outside the base range of the
type.
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
4.5.4 Unary Adding Operators
Static Semantics
1 The unary adding operators + (identity) and - (negation) are predefined
for every specific numeric type T with their conventional meaning. They have
the following specifications:
2 function "+"(Right : T) return T
function "-"(Right : T) return T
NOTES
3 16 For modular integer types, the unary adding operator -, when given
a nonzero operand, returns the result of subtracting the value of the
operand from the modulus; for a zero operand, the result is zero.
4.5.5 Multiplying Operators
Static Semantics
1 The multiplying operators * (multiplication), / (division), mod (modulus),
and rem (remainder) are predefined for every specific integer type T:
2 function "*" (Left, Right : T) return T
function "/" (Left, Right : T) return T
function "mod"(Left, Right : T) return T
function "rem"(Left, Right : T) return T
3 Signed integer multiplication has its conventional meaning.
4 Signed integer division and remainder are defined by the relation:
5 A = (A/B)*B + (A rem B)
6 where (A rem B) has the sign of A and an absolute value less than the
absolute value of B. Signed integer division satisfies the identity:
7 (-A)/B = -(A/B) = A/(-B)
8/3 The signed integer modulus operator is defined such that the result of A
mod B is either zero, or has the sign of B and an absolute value less than the
absolute value of B; in addition, for some signed integer value N, this result
satisfies the relation:
9 A = B*N + (A mod B)
10 The multiplying operators on modular types are defined in terms of the
corresponding signed integer operators, followed by a reduction modulo the
modulus if the result is outside the base range of the type (which is only
possible for the "*" operator).
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:
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:
19 function "*"(Left, Right : universal_fixed) return universal_fixed
function "/"(Left, Right : universal_fixed) return universal_fixed
Name Resolution Rules
19.1/2 The above two fixed-fixed multiplying operators shall not be used in a
context where the expected type for the result is itself universal_fixed - the
context has to identify some other numeric type to which the result is to be
converted, either explicitly or implicitly. Unless the predefined universal
operator is identified using an expanded name with prefix denoting the package
Standard, an explicit conversion is required on the result when using the
above fixed-fixed multiplication operator if either operand is of a type
having a user-defined primitive multiplication operator such that:
19.2/3 * it is declared immediately within the same declaration list as the
type or any partial or incomplete view thereof; and
19.3/2 * both of its formal parameters are of a fixed-point type.
19.4/2 A corresponding requirement applies to the universal fixed-fixed
division operator.
Paragraph 20 was deleted.
Dynamic Semantics
21 The multiplication and division operators for real types have their
conventional meaning. For floating point types, the accuracy of the result is
determined by the precision of the result type. For decimal fixed point types,
the result is truncated toward zero if the mathematical result is between two
multiples of the small of the specific result type (possibly determined by
context); for ordinary fixed point types, if the mathematical result is
between two multiples of the small, it is unspecified which of the two is the
result.
22 The exception Constraint_Error is raised by integer division, rem, and mod
if the right operand is zero. Similarly, for a real type T with
T'Machine_Overflows True, division by zero raises Constraint_Error.
NOTES
23 17 For positive A and B, A/B is the quotient and A rem B is the
remainder when A is divided by B. The following relations are
satisfied by the rem operator:
24 A rem (-B) = A rem B
(-A) rem B = -(A rem B)
25 18 For any signed integer K, the following identity holds:
26 A mod B = (A + K*B) mod B
27 The relations between signed integer division, remainder, and modulus
are illustrated by the following table:
28 A B A/B A rem B A mod B A B A/B A rem B A mod B
29 10 5 2 0 0 -10 5 -2 0 0
11 5 2 1 1 -11 5 -2 -1 4
12 5 2 2 2 -12 5 -2 -2 3
13 5 2 3 3 -13 5 -2 -3 2
14 5 2 4 4 -14 5 -2 -4 1
30 A B A/B A rem B A mod B A B A/B A rem B A mod B
10 -5 -2 0 0 -10 -5 2 0 0
11 -5 -2 1 -4 -11 -5 2 -1 -1
12 -5 -2 2 -3 -12 -5 2 -2 -2
13 -5 -2 3 -2 -13 -5 2 -3 -3
14 -5 -2 4 -1 -14 -5 2 -4 -4
Examples
31 Examples of expressions involving multiplying operators:
32 I : Integer := 1;
J : Integer := 2;
K : Integer := 3;
33 X : Real := 1.0; -- see 3.5.7
Y : Real := 2.0;
34 F : Fraction := 0.25; -- see 3.5.9
G : Fraction := 0.5;
35 Expression Value Result Type
I*J 2 same as I and J, that is, Integer
K/J 1 same as K and J, that is, Integer
K mod J 1 same as K and J, that is, Integer
X/Y 0.5 same as X and Y, that is, Real
F/2 0.125 same as F, that is, Fraction
3*F 0.75 same as F, that is, Fraction
0.75*G 0.375
universal_fixed, implicitly convertible
to any fixed point type
Fraction(F*G) 0.125
Fraction, as stated by the conversion
Real(J)*Y 4.0
Real, the type of both operands after
conversion of J
4.5.6 Highest Precedence Operators
Static Semantics
1 The highest precedence unary operator abs (absolute value) is predefined
for every specific numeric type T, with the following specification:
2 function "abs"(Right : T) return T
3 The highest precedence unary operator not (logical negation) is predefined
for every boolean type T, every modular type T, and for every one-dimensional
array type T whose components are of a boolean type, with the following
specification:
4 function "not"(Right : T) return T
5 The result of the operator not for a modular type is defined as the
difference between the high bound of the base range of the type and the value
of the operand. For a binary modulus, this corresponds to a bit-wise
complement of the binary representation of the value of the operand.
6 The operator not that applies to a one-dimensional array of boolean
components yields a one-dimensional boolean array with the same bounds; each
component of the result is obtained by logical negation of the corresponding
component of the operand (that is, the component that has the same index
value). A check is made that each component of the result belongs to the
component subtype; the exception Constraint_Error is raised if this check
fails.
7 The highest precedence exponentiation operator ** is predefined for every
specific integer type T with the following specification:
8 function "**"(Left : T; Right : Natural) return T
9 Exponentiation is also predefined for every specific floating point type
as well as root_real, with the following specification (where T is root_real
or the floating point type):
10 function "**"(Left : T; Right : Integer'Base) return T
11/3 The right operand of an exponentiation is the exponent. The value of X**N
with the value of the exponent N positive is the same as the value of X*X*...X
(with N-1 multiplications) except that the multiplications are associated in
an arbitrary order. With N equal to zero, the result is one. With the value of
N negative (only defined for a floating point operand), the result is the
reciprocal of the result using the absolute value of N as the exponent.
Implementation Permissions
12 The implementation of exponentiation for the case of a negative exponent
is allowed to raise Constraint_Error if the intermediate result of the
repeated multiplications is outside the safe range of the type, even though
the final result (after taking the reciprocal) would not be. (The best machine
approximation to the final result in this case would generally be 0.0.)
NOTES
13 19 As implied by the specification given above for exponentiation of
an integer type, a check is made that the exponent is not negative.
Constraint_Error is raised if this check fails.
4.5.7 Conditional Expressions
1/3 A conditional_expression selects for evaluation at most one of the
enclosed dependent_expressions, depending on a decision among the
alternatives. One kind of conditional_expression is the if_expression, which
selects for evaluation a dependent_expression depending on the value of one or
more corresponding conditions. The other kind of conditional_expression is the
case_expression, which selects for evaluation one of a number of alternative
dependent_expressions; the chosen alternative is determined by the value of a
selecting_expression.
Syntax
2/3 conditional_expression ::= if_expression | case_expression
3/3 if_expression ::=
if condition then dependent_expression
{elsif condition then dependent_expression}
[else dependent_expression]
4/3 condition ::= boolean_expression
5/3 case_expression ::=
case selecting_expression is
case_expression_alternative {,
case_expression_alternative}
6/3 case_expression_alternative ::=
when discrete_choice_list =>
dependent_expression
7/3 Wherever the Syntax Rules allow an expression, a
conditional_expression may be used in place of the expression, so long
as it is immediately surrounded by parentheses.
Name Resolution Rules
8/3 If a conditional_expression is expected to be of a type T, then each
dependent_expression of the conditional_expression is expected to be of type
T. Similarly, if a conditional_expression is expected to be of some class of
types, then each dependent_expression of the conditional_expression is subject
to the same expectation. If a conditional_expression shall resolve to be of a
type T, then each dependent_expression shall resolve to be of type T.
9/3 The possible types of a conditional_expression are further determined as
follows:
10/3 * If the conditional_expression is the operand of a type conversion,
the type of the conditional_expression is the target type of the
conversion; otherwise,
11/3 * If all of the dependent_expressions are of the same type, the type of
the conditional_expression is that type; otherwise,
12/3 * If a dependent_expression is of an elementary type, the type of the
conditional_expression shall be covered by that type; otherwise,
13/3 * If the conditional_expression is expected to be of type T or shall
resolve to type T, then the conditional_expression is of type T.
14/3 A condition is expected to be of any boolean type.
15/3 The expected type for the selecting_expression and the discrete_choices
are as for case statements (see 5.4).
Legality Rules
16/3 All of the dependent_expressions shall be convertible (see 4.6) to the
type of the conditional_expression.
17/3 If the expected type of a conditional_expression is a specific tagged
type, all of the dependent_expressions of the conditional_expression shall be
dynamically tagged, or none shall be dynamically tagged. In this case, the
conditional_expression is dynamically tagged if all of the
dependent_expressions are dynamically tagged, is tag-indeterminate if all of the
dependent_expressions are tag-indeterminate, and is statically tagged
otherwise.
18/3 If there is no else dependent_expression, the if_expression shall be of a
boolean type.
19/3 All Legality Rules that apply to the discrete_choices of a
case_statement (see 5.4) also apply to the discrete_choices of a
case_expression except within an instance of a generic unit.
Dynamic Semantics
20/3 For the evaluation of an if_expression, the condition specified after if,
and any conditions specified after elsif, are evaluated in succession
(treating a final else as elsif True then), until one evaluates to True or all
conditions are evaluated and yield False. If a condition evaluates to True,
the associated dependent_expression is evaluated, converted to the type of the
if_expression, and the resulting value is the value of the if_expression.
Otherwise (when there is no else clause), the value of the if_expression is
True.
21/3 For the evaluation of a case_expression, the selecting_expression is
first evaluated. If the value of the selecting_expression is covered by the
discrete_choice_list of some case_expression_alternative, then the
dependent_expression of the case_expression_alternative is evaluated, converted to the
type of the case_expression, and the resulting value is the value of the
case_expression. Otherwise (the value is not covered by any
discrete_choice_list, perhaps due to being outside the base range),
Constraint_Error is raised.
4.5.8 Quantified Expressions
0.1/4 Quantified expressions provide a way to write universally and
existentially quantified predicates over containers and arrays.
Syntax
1/3 quantified_expression ::= for quantifier
loop_parameter_specification => predicate
| for quantifier iterator_specification => predicate
2/3 quantifier ::= all | some
3/3 predicate ::= boolean_expression
4/3 Wherever the Syntax Rules allow an expression, a
quantified_expression may be used in place of the expression, so long
as it is immediately surrounded by parentheses.
Name Resolution Rules
5/3 The expected type of a quantified_expression is any Boolean type. The
predicate in a quantified_expression is expected to be of the same type.
Dynamic Semantics
6/4 For the evaluation of a quantified_expression, the
loop_parameter_specification or iterator_specification is first elaborated.
The evaluation of a quantified_expression then evaluates the predicate for the
values of the loop parameter in the order specified by the
loop_parameter_specification (see 5.5) or iterator_specification (see 5.5.2).
7/3 The value of the quantified_expression is determined as follows:
8/4 * If the quantifier is all, the expression is False if the evaluation of
any predicate yields False; evaluation of the quantified_expression
stops at that point. Otherwise (every predicate has been evaluated and
yielded True), the expression is True. Any exception raised by
evaluation of the predicate is propagated.
9/4 * If the quantifier is some, the expression is True if the evaluation of
any predicate yields True; evaluation of the quantified_expression
stops at that point. Otherwise (every predicate has been evaluated and
yielded False), the expression is False. Any exception raised by
evaluation of the predicate is propagated.
Examples
10/3 The postcondition for a sorting routine on an array A with an index
subtype T can be written:
11/3 Post => (A'Length < 2 or else
(for all I in A'First .. T'Pred(A'Last) => A (I) <= A (T'Succ (I))))
12/3 The assertion that a positive number is composite (as opposed to prime)
can be written:
13/3 pragma Assert (for some X in 2 .. N / 2 => N mod X = 0);
4.6 Type Conversions
1/3 Explicit type conversions, both value conversions and view conversions,
are allowed between closely related types as defined below. This subclause
also defines rules for value and view conversions to a particular subtype of a
type, both explicit ones and those implicit in other constructs.
Syntax
2 type_conversion ::=
subtype_mark(expression)
| subtype_mark(name)
3 The target subtype of a type_conversion is the subtype denoted by the
subtype_mark. The operand of a type_conversion is the expression or name
within the parentheses; its type is the operand type.
4/3 One type is convertible to a second type if a type_conversion with the
first type as operand type and the second type as target type is legal
according to the rules of this subclause. Two types are convertible if each is
convertible to the other.
5/2 A type_conversion whose operand is the name of an object is called a view
conversion if both its target type and operand type are tagged, or if it
appears in a call as an actual parameter of mode out or in out; other
type_conversions are called value conversions.
Name Resolution Rules
6 The operand of a type_conversion is expected to be of any type.
7 The operand of a view conversion is interpreted only as a name; the
operand of a value conversion is interpreted as an expression.
Legality Rules
8/2 In a view conversion for an untagged type, the target type shall be
convertible (back) to the operand type.
Paragraphs 9 through 20 were reorganized and moved below.
21/3 If there is a type (other than a root numeric type) that is an ancestor
of both the target type and the operand type, or both types are class-wide
types, then at least one of the following rules shall apply:
21.1/2 * The target type shall be untagged; or
22 * The operand type shall be covered by or descended from the target
type; or
23/2 * The operand type shall be a class-wide type that covers the target
type; or
23.1/2 * 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.
24/3 If there is no type (other than a root numeric type) that is the ancestor
of both the target type and the operand type, and they are not both class-wide
types, one of the following rules shall apply:
24.1/2 * If the target type is a numeric type, then the operand type shall
be a numeric type.
24.2/2 * If the target type is an array type, then the operand type shall be
an array type. Further:
24.3/2 * The types shall have the same dimensionality;
24.4/2 * Corresponding index types shall be convertible;
24.5/2 * The component subtypes shall statically match;
24.6/2 * If the component types are anonymous access types, then the
accessibility level of the operand type shall not be statically
deeper than that of the target type;
24.7/2 * Neither the target type nor the operand type shall be limited;
24.8/2 * If the target type of a view conversion has aliased components,
then so shall the operand type; and
24.9/2 * The operand type of a view conversion shall not have a tagged,
private, or volatile subcomponent.
24.10/2 * If the target type is universal_access, then the operand type
shall be an access type.
24.11/2 * 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.12/2 * If the target type is an access-to-variable type, then the operand
type shall be an access-to-variable type;
24.13/2 * If the target designated type is tagged, then the operand
designated type shall be convertible to the target designated
type;
24.14/2 * If the target designated type is not tagged, then the designated
types shall be the same, and either:
24.15/2 * the designated subtypes shall statically match; or
24.16/2 * 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.17/4 * The accessibility level of the operand type shall not be
statically deeper than that of the target type, unless the target
type is an anonymous access type of a stand-alone object. If the
target type is that of such a stand-alone object, the
accessibility level of the operand type shall not be statically
deeper than that of the declaration of the stand-alone object.
24.18/2 * If the target type is a pool-specific access-to-object type, then
the operand type shall be universal_access.
24.19/2 * If the target type is an access-to-subprogram type, then the
operand type shall be universal_access or an access-to-subprogram
type. Further, if the operand type is not universal_access:
24.20/3 * The designated profiles shall be subtype conformant.
24.21/4 * The accessibility level of the operand type shall not be
statically deeper than that of the target type. If the operand
type is declared within a generic body, the target type shall be
declared within the generic body.
24.22/4 In addition to the places where Legality Rules normally apply (see
12.3), these rules apply also in the private part of an instance of a generic
unit.
Static Semantics
25 A type_conversion that is a value conversion denotes the value that is the
result of converting the value of the operand to the target subtype.
26/3 A type_conversion that is a view conversion denotes a view of the object
denoted by the operand. This view is a variable of the target type if the
operand denotes a variable; otherwise, it is a constant of the target type.
27 The nominal subtype of a type_conversion is its target subtype.
Dynamic Semantics
28 For the evaluation of a type_conversion that is a value conversion, the
operand is evaluated, and then the value of the operand is converted to a
corresponding value of the target type, if any. If there is no value of the
target type that corresponds to the operand value, Constraint_Error is raised;
this can only happen on conversion to a modular type, and only when the
operand value is outside the base range of the modular type. Additional rules
follow:
29 * Numeric Type Conversion
30 * If the target and the operand types are both integer types, then
the result is the value of the target type that corresponds to the
same mathematical integer as the operand.
31 * If the target type is a decimal fixed point type, then the result
is truncated (toward 0) if the value of the operand is not a
multiple of the small of the target type.
32 * If the target type is some other real type, then the result is
within the accuracy of the target type (see G.2, "
Numeric Performance Requirements", for implementations that
support the Numerics Annex).
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).
34 * Enumeration Type Conversion
35 * The result is the value of the target type with the same position
number as that of the operand value.
36 * Array Type Conversion
37 * If the target subtype is a constrained array subtype, then a check
is made that the length of each dimension of the value of the
operand equals the length of the corresponding dimension of the
target subtype. The bounds of the result are those of the target
subtype.
38 * If the target subtype is an unconstrained array subtype, then the
bounds of the result are obtained by converting each bound of the
value of the operand to the corresponding index type of the target
type. For each nonnull index range, a check is made that the
bounds of the range belong to the corresponding index subtype.
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.1/2 * 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.
40 * Composite (Non-Array) Type Conversion
41 * The value of each nondiscriminant component of the result is that
of the matching component of the operand value.
42 * The tag of the result is that of the operand. If the operand type
is class-wide, a check is made that the tag of the operand
identifies a (specific) type that is covered by or descended from
the target type.
43 * For each discriminant of the target type that corresponds to a
discriminant of the operand type, its value is that of the
corresponding discriminant of the operand value; if it corresponds
to more than one discriminant of the operand type, a check is made
that all these discriminants are equal in the operand value.
44 * For each discriminant of the target type that corresponds to a
discriminant that is specified by the derived_type_definition for
some ancestor of the operand type (or if class-wide, some ancestor
of the specific type identified by the tag of the operand), its
value in the result is that specified by the
derived_type_definition.
45 * For each discriminant of the operand type that corresponds to a
discriminant that is specified by the derived_type_definition for
some ancestor of the target type, a check is made that in the
operand value it equals the value specified for it.
46 * For each discriminant of the result, a check is made that its
value belongs to its subtype.
47 * Access Type Conversion
48/3 * For an access-to-object type, a check is made that the
accessibility level of the operand type is not deeper than that of
the target type, unless the target type is an anonymous access
type of a stand-alone object. If the target type is that of such a
stand-alone object, a check is made that the accessibility level
of the operand type is not deeper than that of the declaration of
the stand-alone object; then if the check succeeds, the
accessibility level of the target type becomes that of the operand
type.
49/2 * If the operand value is null, the result of the conversion is the
null value of the target type.
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.
51/4 After conversion of the value to the target type, if the target subtype
is constrained, a check is performed that the value satisfies this constraint.
If the target subtype excludes null, then a check is made that the value is
not null. If predicate checks are enabled for the target subtype (see 3.2.4),
a check is performed that the value satisfies the predicates of the target
subtype.
52 For the evaluation of a view conversion, the operand name is evaluated,
and a new view of the object denoted by the operand is created, whose type is
the target type; if the target type is composite, checks are performed as
above for a value conversion.
53 The properties of this new view are as follows:
54/1 * If the target type is composite, the bounds or discriminants (if any)
of the view are as defined above for a value conversion; each
nondiscriminant component of the view denotes the matching component
of the operand object; the subtype of the view is constrained if
either the target subtype or the operand object is constrained, or if
the target subtype is indefinite, or if the operand type is a
descendant of the target type and has discriminants that were not
inherited from the target type;
55 * If the target type is tagged, then an assignment to the view assigns
to the corresponding part of the object denoted by the operand;
otherwise, an assignment to the view assigns to the object, after
converting the assigned value to the subtype of the object (which
might raise Constraint_Error);
56/4 * Reading the value of the view yields the result of converting the
value of the operand object to the target subtype (which might raise
Constraint_Error), except if the object is of an elementary type and
the view conversion is passed as an out parameter; in this latter
case, the value of the operand object may be used to initialize the
formal parameter without checking against any constraint of the target
subtype (as described more precisely in 6.4.1).
57/4 If an Accessibility_Check fails, Program_Error is raised. If a predicate
check fails, the effect is as defined in subclause 3.2.4, "
Subtype Predicates". Any other check associated with a conversion raises
Constraint_Error if it fails.
58 Conversion to a type is the same as conversion to an unconstrained subtype
of the type.
58.1/4 Evaluation of a value conversion of a composite type either creates a
new anonymous object (similar to the object created by the evaluation of an
aggregate or a function call) or yields a new view of the operand object
without creating a new object:
58.2/4 * If the target type is a by-reference type and there is a type that
is an ancestor of both the target type and the operand type then no
new object is created;
58.3/4 * If the target type is an array type having aliased components and
the operand type is an array type having unaliased components, then a
new object is created;
58.4/4 * Otherwise, it is unspecified whether a new object is created.
58.5/4 If a new object is created, then the initialization of that object is
an assignment operation.
NOTES
59 20 In addition to explicit type_conversions, type conversions are
performed implicitly in situations where the expected type and the
actual type of a construct differ, as is permitted by the type
resolution rules (see 8.6). For example, an integer literal is of the
type universal_integer, and is implicitly converted when assigned to a
target of some specific integer type. Similarly, an actual parameter
of a specific tagged type is implicitly converted when the
corresponding formal parameter is of a class-wide type.
60 Even when the expected and actual types are the same, implicit subtype
conversions are performed to adjust the array bounds (if any) of an
operand to match the desired target subtype, or to raise
Constraint_Error if the (possibly adjusted) value does not satisfy the
constraints of the target subtype.
61/2 21 A ramification of the overload resolution rules is that the
operand of an (explicit) type_conversion cannot be an allocator, an
aggregate, a string_literal, a character_literal, or an
attribute_reference for an Access or Unchecked_Access attribute.
Similarly, such an expression enclosed by parentheses is not allowed.
A qualified_expression (see 4.7) can be used instead of such a
type_conversion.
62 22 The constraint of the target subtype has no effect for a
type_conversion of an elementary type passed as an out parameter.
Hence, it is recommended that the first subtype be specified as the
target to minimize confusion (a similar recommendation applies to
renaming and generic formal in out objects).
Examples
63 Examples of numeric type conversion:
64 Real(2*J) -- value is converted to floating point
Integer(1.6) -- value is 2
Integer(-0.4) -- value is 0
65 Example of conversion between derived types:
66 type A_Form is new B_Form;
67 X : A_Form;
Y : B_Form;
68 X := A_Form(Y);
Y := B_Form(X); -- the reverse conversion
69 Examples of conversions between array types:
70 type Sequence is array (Integer range <>) of Integer;
subtype Dozen is Sequence(1 .. 12);
Ledger : array(1 .. 100) of Integer;
71 Sequence(Ledger) -- bounds are those of Ledger
Sequence(Ledger(31 .. 42)) -- bounds are 31 and 42
Dozen(Ledger(31 .. 42)) -- bounds are those of Dozen
4.7 Qualified Expressions
1 A qualified_expression is used to state explicitly the type, and to verify
the subtype, of an operand that is either an expression or an aggregate.
Syntax
2 qualified_expression ::=
subtype_mark'(expression) | subtype_mark'aggregate
Name Resolution Rules
3 The operand (the expression or aggregate) shall resolve to be of the type
determined by the subtype_mark, or a universal type that covers it.
Static Semantics
3.1/3 If the operand of a qualified_expression denotes an object, the
qualified_expression denotes a constant view of that object. The nominal
subtype of a qualified_expression is the subtype denoted by the subtype_mark.
Dynamic Semantics
4/4 The evaluation of a qualified_expression evaluates the operand (and if of
a universal type, converts it to the type determined by the subtype_mark) and
checks that its value belongs to the subtype denoted by the subtype_mark. The
exception Constraint_Error is raised if this check fails. Furthermore, if
predicate checks are enabled for the subtype denoted by the subtype_mark, a
check is performed as defined in subclause 3.2.4, "Subtype Predicates" that
the value satifies the predicates of the subtype.
NOTES
5 23 When a given context does not uniquely identify an expected type,
a qualified_expression can be used to do so. In particular, if an
overloaded name or aggregate is passed to an overloaded subprogram, it
might be necessary to qualify the operand to resolve its type.
Examples
6 Examples of disambiguating expressions using qualification:
7 type Mask is (Fix, Dec, Exp, Signif);
type Code is (Fix, Cla, Dec, Tnz, Sub);
8 Print (Mask'(Dec)); -- Dec is of type Mask
Print (Code'(Dec)); -- Dec is of type Code
9 for J in Code'(Fix) .. Code'(Dec) loop ... -- qualification needed for either Fix or Dec
for J in Code range Fix .. Dec loop ... -- qualification unnecessary
for J in Code'(Fix) .. Dec loop ... -- qualification unnecessary for Dec
10 Dozen'(1 | 3 | 5 | 7 => 2, others => 0) -- see 4.6
4.8 Allocators
1 The evaluation of an allocator creates an object and yields an access
value that designates the object.
Syntax
2/3 allocator ::=
new [subpool_specification] subtype_indication
| new [subpool_specification] qualified_expression
2.1/3 subpool_specification ::= (subpool_handle_name)
2.2/3 For an allocator with a subtype_indication, the subtype_indication
shall not specify a null_exclusion.
Name Resolution Rules
3/3 The expected type for an allocator shall be a single access-to-object type
with designated type D such that either D covers the type determined by the
subtype_mark of the subtype_indication or qualified_expression, or the
expected type is anonymous and the determined type is D'Class. A
subpool_handle_name is expected to be of any type descended from
Subpool_Handle, which is the type used to identify a subpool, declared in
package System.Storage_Pools.Subpools (see 13.11.4).
Legality Rules
4 An initialized allocator is an allocator with a qualified_expression. An
uninitialized allocator is one with a subtype_indication. In the
subtype_indication of an uninitialized allocator, a constraint is permitted
only if the subtype_mark denotes an unconstrained composite subtype; if there
is no constraint, then the subtype_mark shall denote a definite subtype.
5/2 If the type of the allocator is an access-to-constant type, the
allocator shall be an initialized allocator.
5.1/3 If a subpool_specification is given, the type of the storage pool of the
access type shall be a descendant of Root_Storage_Pool_With_Subpools.
5.2/3 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.3/3 If the subtype determined by the subtype_indication or
qualified_expression of the allocator has one or more access discriminants,
then the accessibility level of the anonymous access type of each access
discriminant shall not be statically deeper than that of the type of the
allocator (see 3.10.2).
5.4/3 An allocator shall not be of an access type for which the Storage_Size
has been specified by a static expression with value zero or is defined by the
language to be zero.
5.5/3 If the designated type of the type of the allocator is limited, then the
allocator shall not be used to define the value of an access discriminant,
unless the discriminated type is immutably limited (see 7.5).
5.6/3 In addition to the places where Legality Rules normally apply (see
12.3), these rules apply also in the private part of an instance of a generic
unit.
Static Semantics
6/3 If the designated type of the type of the allocator is elementary, then
the subtype of the created object is the designated subtype. If the designated
type is composite, then the subtype of the created object is the designated
subtype when the designated subtype is constrained or there is an ancestor of
the designated type that has a constrained partial view; otherwise, the
created object is constrained by its initial value (even if the designated
subtype is unconstrained with defaults).
Dynamic Semantics
7/2 For the evaluation of an initialized allocator, the evaluation of the
qualified_expression is performed first. An object of the designated type is
created and the value of the qualified_expression is converted to the
designated subtype and assigned to the object.
8 For the evaluation of an uninitialized allocator, the elaboration of the
subtype_indication is performed first. Then:
9/2 * If the designated type is elementary, an object of the designated
subtype is created and any implicit initial value is assigned;
10/2 * If the designated type is composite, an object of the designated type
is created with tag, if any, determined by the subtype_mark of the
subtype_indication. This object is then initialized by default (see
3.3.1) using the subtype_indication to determine its nominal subtype.
A check is made that the value of the object belongs to the designated
subtype. Constraint_Error is raised if this check fails. This check
and the initialization of the object are performed in an arbitrary
order.
10.1/3 For any allocator, if the designated type of the type of the
allocator is class-wide, then a check is made that the master of the type
determined by the subtype_indication, or by the tag of the value of the
qualified_expression, includes the elaboration of the type of the allocator.
If any part of the subtype determined by the subtype_indication or
qualified_expression of the allocator (or by the tag of the value if the type
of the qualified_expression is class-wide) has one or more access
discriminants, then a check is made that the accessibility level of the
anonymous access type of each access discriminant is not deeper than that of
the type of the allocator. Program_Error is raised if either such check fails.
10.2/2 If the object to be created by an allocator has a controlled or
protected part, and the finalization of the collection of the type of the
allocator (see 7.6.1) has started, Program_Error is raised.
10.3/2 If the object to be created by an allocator contains any tasks, and the
master of the type of the allocator is completed, and all of the dependent
tasks of the master are terminated (see 9.3), then Program_Error is raised.
10.4/3 If the allocator includes a subpool_handle_name, Constraint_Error is
raised if the subpool handle is null. Program_Error is raised if the subpool
does not belong (see 13.11.4) to the storage pool of the access type of the
allocator.
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 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.
NOTES
12 24 Allocators cannot create objects of an abstract type. See 3.9.3.
13 25 If any part of the created object is controlled, the
initialization includes calls on corresponding Initialize or Adjust
procedures. See 7.6.
14 26 As explained in 13.11, "Storage Management", the storage for an
object allocated by an allocator comes from a storage pool (possibly
user defined). The exception Storage_Error is raised by an allocator
if there is not enough storage. Instances of Unchecked_Deallocation
may be used to explicitly reclaim storage.
15/3 27 Implementations are permitted, but not required, to provide
garbage collection.
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
4.9 Static Expressions and Static Subtypes
1 Certain expressions of a scalar or string type are defined to be static.
Similarly, certain discrete ranges are defined to be static, and certain
scalar and string subtypes are defined to be static subtypes. Static means
determinable at compile time, using the declared properties or values of the
program entities.
2 A static expression is a scalar or string expression that is one of the
following:
3 * a numeric_literal;
4 * a string_literal of a static string subtype;
5 * a name that denotes the declaration of a named number or a static
constant;
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;
7 * an attribute_reference that denotes a scalar value, and whose prefix
denotes a static scalar subtype;
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;
11/4 * a membership test whose tested_simple_expression is a static
expression, and whose membership_choice_list consists only of
membership_choices that are either static choice_simple_expressions,
static ranges, or subtype_marks that denote a static (scalar or
string) subtype;
12 * a short-circuit control form both of whose relations are static
expressions;
12.1/3 * a conditional_expression all of whose conditions,
selecting_expressions, and dependent_expressions are static expressions;
13 * a static expression enclosed in parentheses.
14 A name statically denotes an entity if it denotes the entity and:
15 * It is a direct_name, expanded name, or character_literal, and it
denotes a declaration other than a renaming_declaration; or
16 * It is an attribute_reference whose prefix statically denotes some
entity; or
17 * It denotes a renaming_declaration with a name that statically denotes
the renamed entity.
18 A static function is one of the following:
19 * a predefined operator whose parameter and result types are all scalar
types none of which are descendants of formal scalar types;
20 * a predefined concatenation operator whose result type is a string type;
21 * an enumeration literal;
22 * a language-defined attribute that is a function, if the prefix denotes
a static scalar subtype, and if the parameter and result types are
scalar.
23 In any case, a generic formal subprogram is not a static function.
24 A static constant is a constant view declared by a full constant
declaration or an object_renaming_declaration with a static nominal subtype,
having a value defined by a static scalar expression or by a static string
expression whose value has a length not exceeding the maximum length of a
string_literal in the implementation.
25 A static range is a range whose bounds are static expressions, or a range_-
attribute_reference that is equivalent to such a range. A static discrete_-
range is one that is a static range or is a subtype_indication that defines a
static scalar subtype. The base range of a scalar type is a static range,
unless the type is a descendant of a formal scalar type.
26/3 A static subtype is either a static scalar subtype or a static string
subtype. A static scalar subtype is an unconstrained scalar subtype whose type
is not a descendant of a formal type, or a constrained scalar subtype formed
by imposing a compatible static constraint on a static scalar subtype. A
static string subtype is an unconstrained string subtype whose index subtype
and component subtype are static, or a constrained string subtype formed by
imposing a compatible static constraint on a static string subtype. In any
case, the subtype of a generic formal object of mode in out, and the result
subtype of a generic formal function, are not static. Also, a subtype is not
static if any Dynamic_Predicate specifications apply to it.
27 The different kinds of static constraint are defined as follows:
28 * A null constraint is always static;
29 * A scalar constraint is static if it has no range_constraint, or one
with a static range;
30 * An index constraint is static if each discrete_range is static, and
each index subtype of the corresponding array type is static;
31 * A discriminant constraint is static if each expression of the
constraint is static, and the subtype of each discriminant is static.
31.1/2 In any case, the constraint of the first subtype of a scalar formal
type is neither static nor null.
32 A subtype is statically constrained if it is constrained, and its
constraint is static. An object is statically constrained if its nominal
subtype is statically constrained, or if it is a static string constant.
Legality Rules
32.1/3 An expression is statically unevaluated if it is part of:
32.2/3 * the right operand of a static short-circuit control form whose
value is determined by its left operand; or
32.3/3 * a dependent_expression of an if_expression whose associated
condition is static and equals False; or
32.4/3 * a condition or dependent_expression of an if_expression where the
condition corresponding to at least one preceding
dependent_expression of the if_expression is static and equals True; or
32.5/3 * a dependent_expression of a case_expression whose
selecting_expression is static and whose value is not covered by the
corresponding discrete_choice_list; or
32.6/4 * a choice_simple_expression (or a simple_expression of a range that
occurs as a membership_choice of a membership_choice_list) of a static
membership test that is preceded in the enclosing
membership_choice_list by another item whose individual membership
test (see 4.5.2) statically yields True.
33/3 A static expression is evaluated at compile time except when it is
statically unevaluated. The compile-time evaluation of a static expression is
performed exactly, without performing Overflow_Checks. For a static expression
that is evaluated:
34/3 * The expression is illegal if its evaluation fails a language-defined
check other than Overflow_Check. For the purposes of this evaluation,
the assertion policy is assumed to be Check.
35/2 * If the expression is not part of a larger static expression and the
expression is expected to be of a single specific type, then its value
shall be within the base range of its expected type. Otherwise, the
value may be arbitrarily large or small.
36/2 * If the expression is of type universal_real and its expected type is
a decimal fixed point type, then its value shall be a multiple of the
small of the decimal type. This restriction does not apply if the
expected type is a descendant of a formal scalar type (or a
corresponding actual type in an instance).
37/2 In addition to the places where Legality Rules normally apply (see 12.3
), the above restrictions also apply in the private part of an instance of a
generic unit.
Implementation Requirements
38/2 For a real static expression that is not part of a larger static
expression, and whose expected type is not a descendant of a formal type, the
implementation shall round or truncate the value (according to the
Machine_Rounds attribute of the expected type) to the nearest machine number
of the expected type; if the value is exactly half-way between two machine
numbers, the rounding performed is implementation-defined. If the expected
type is a descendant of a formal type, or if the static expression appears in
the body of an instance of a generic unit and the corresponding expression is
nonstatic in the corresponding generic body, then no special rounding or
truncating is required - normal accuracy rules apply (see Annex G).
Implementation Advice
38.1/2 For a real static expression that is not part of a larger static
expression, and whose expected type is not a descendant of a formal type, the
rounding should be the same as the default rounding for the target system.
NOTES
39 28 An expression can be static even if it occurs in a context where
staticness is not required.
40 29 A static (or run-time) type_conversion from a real type to an
integer type performs rounding. If the operand value is exactly
half-way between two integers, the rounding is performed away from
zero.
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)
4.9.1 Statically Matching Constraints and Subtypes
Static Semantics
1/2 A constraint statically matches another constraint if:
1.1/2 * both are null constraints;
1.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 * both are nonstatic and come from the same formal_type_declaration.
2/3 A subtype statically matches another subtype of the same type if they have
statically matching constraints, all predicate specifications that apply to
them come from the same declarations, and, for access subtypes, either both or
neither exclude null. Two anonymous access-to-object subtypes statically match
if their designated subtypes statically match, and either both or neither
exclude null, and either both or neither are access-to-constant. Two anonymous
access-to-subprogram subtypes statically match if their designated profiles
are subtype conformant, and either both or neither exclude null.
3 Two ranges of the same type statically match if both result from the same
evaluation of a range, or if both are static and have equal corresponding
bounds.
4/3 A constraint is statically compatible with a scalar subtype if it
statically matches the constraint of the subtype, or if both are static and
the constraint is compatible with the subtype. A constraint is statically
compatible with an access or composite subtype if it statically matches the
constraint of the subtype, or if the subtype is unconstrained.
5/3 Two statically matching subtypes are statically compatible with each
other. In addition, a subtype S1 is statically compatible with a subtype S2
if:
6/3 * the constraint of S1 is statically compatible with S2, and
7/3 * if S2 excludes null, so does S1, and
8/3 * either:
9/3 * all predicate specifications that apply to S2 apply also to S1, or
10/4 * both subtypes are static, every value that satisfies the
predicates of S1 also satisfies the predicates of S2, and it is
not the case that both types each have at least one applicable
predicate specification, predicate checks are enabled (see
11.4.2) for S2, and predicate checks are not enabled for S1.
Generated by dwww version 1.15 on Thu May 23 19:13:55 CEST 2024.