Go to the first, previous, next, last section, table of contents.

4.6 Type Conversions

Explicit type conversions, both value conversions and view conversions, are allowed between closely related types as defined below. This clause also defines rules for value and view conversions to a particular subtype of a type, both explicit ones and those implicit in other constructs.
Syntax

type_conversion ::=
     subtype_mark(expression)
   | subtype_mark(name)

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.
One type is convertible to a second type if a type_conversion with the first type as operand type and the second type as target type is legal according to the rules of this clause. Two types are convertible if each is convertible to the other.
A type_conversion whose operand is the name of an object is called a view conversion if its target type is tagged, or if it appears as an actual parameter of mode out or in out; other type_conversions are called value conversions.
Name Resolution Rules
The operand of a type_conversion is expected to be of any type.
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
If the target type is a numeric type, then the operand type shall be a numeric type.
If the target type is an array type, then the operand type shall be an array type. Further:
1. The types shall have the same dimensionality;
2. Corresponding index types shall be convertible; and
3. The component subtypes shall statically match.

If the target type is a general access type, then the operand type shall be an access-to-object type. Further:
1. If the target type is an access-to-variable type, then the operand type shall be an access-to-variable type;
2. If the target designated type is tagged, then the operand designated type shall be convertible to the target designated type;
3. If the target designated type is not tagged, then the designated types shall be the same, and either the designated subtypes shall statically match or the target designated subtype shall be discriminated and unconstrained; and
4. The accessibility level of the operand type shall not be statically deeper than that of the target type. In addition to the places where Legality Rules normally apply, See section 12.3 Generic Instantiation, this rule applies also in the private part of an instance of a generic unit.

If the target type is an access-to-subprogram type, then the operand type shall be an access-to-subprogram type. Further:
1. The designated profiles shall be subtype-conformant.
2. The accessibility level of the operand type shall not be statically deeper than that of the target type. In addition to the places where Legality Rules normally apply, See section 12.3 Generic Instantiation, this rule applies also in the private part of an instance of a generic unit. If the operand type is declared within a generic body, the target type shall be declared within the generic body.

If the target type is not included in any of the above four cases, there shall be a type that is an ancestor of both the target type and the operand type. Further, if the target type is tagged, then either:
1. The operand type shall be covered by or descended from the target type; or
2. The operand type shall be a class-wide type that covers the target type.

In a view conversion for an untagged type, the target type shall be convertible (back) to the operand type.
Static Semantics
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.
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.
The nominal subtype of a type_conversion is its target subtype.
Dynamic Semantics
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:
1. Numeric Type Conversion
  1. 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.
  2. 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.
  3. If the target type is some other real type, then the result is within the accuracy of the target type (See section G.2 Numeric Performance Requirements, for implementations that support the Numerics Annex).
  4. 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).

Enumeration Type Conversion
1. The result is the value of the target type with the same position number as that of the operand value.

Array Type Conversion
1. 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.
2. 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.
3. In either array case, the value of each component of the result is that of the matching component of the operand value, See section 4.5.2 Relational Operators and Membership Tests.

Composite (Non-Array) Type Conversion
1. The value of each nondiscriminant component of the result is that of the matching component of the operand value.
2. 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.
3. 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.
4. 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.
5. 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.
6. For each discriminant of the result, a check is made that its value belongs to its subtype.

Access Type Conversion
1. For an access-to-object type, a check is made that the accessibility level of the operand type is not deeper than that of the target type.
2. If the target type is an anonymous access type, a check is made that the value of the operand is not null; if the target is not an anonymous access type, then the result is null if the operand value is null.
3. 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.

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.
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.
The properties of this new view are as follows:
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 operand type is a descendant of the target type, and has discriminants that were not inherited from the target type;
2. 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);
3. Reading the value of the view yields the result of converting the value of the operand object to the target subtype (which might raise Constraint_Error), except if the object is of an access type and the view conversion is passed as an out parameter; in this latter case, the value of the operand object is used to initialize the formal parameter without checking against any constraint of the target subtype, See section 6.4.1 Parameter Associations.

If an Accessibility_Check fails, Program_Error is raised. Any other check associated with a conversion raises Constraint_Error if it fails.
Conversion to a type is the same as conversion to an unconstrained subtype of the type.
NOTES
(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 section 8.6 The Context of Overload Resolution. 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.
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.
(21) A ramification of the overload resolution rules is that the operand of an (explicit) type_conversion cannot be the literal null, 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 section 4.7 Qualified Expressions, can be used instead of such a type_conversion.
(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
Examples of numeric type conversion:

Real(2*J)      --  value is converted to floating point
Integer(1.6)   --  value is 2
Integer(-0.4)  --  value is 0

Example of conversion between derived types:
```
type A_Form is new B_Form;
```
```
X : A_Form;
Y : B_Form;
```

X := A_Form(Y);
Y := B_Form(X);  --  the reverse conversion

Examples of conversions between array types:

type Sequence is array (Integer range <>) of Integer;
subtype Dozen is Sequence(1 .. 12);
Ledger : array(1 .. 100) of Integer;

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

Go to the first, previous, next, last section, table of contents.