4.6 Type Conversions
[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.
One type is convertible
to a second type if
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.
Ramification: Note that “convertible”
is defined in terms of legality of the conversion. Whether the conversion
would raise an exception at run time is irrelevant to this definition.
A view conversion to a
tagged type can appear in any context that requires an object name
including in an object renaming, the prefix
of a selected_component
and if the operand is a variable, on the left side of an assignment_statement
View conversions to other types only occur as actual parameters. Allowing
view conversions of untagged types in all contexts seemed to incur an
undue implementation burden.
A type conversion appearing as an in out
parameter in a generic
instantiation is not a view conversion; the second part of the rule only
applies to subprogram calls, not instantiations.
Name Resolution Rules
This replaces the "must
be determinable" wording of Ada 83. This is equivalent to (but hopefully
more intuitive than) saying that the operand of a type_conversion
is a “complete context.”
The operand of a view conversion is interpreted only
as a name
the operand of a value conversion is interpreted as an expression
This formally resolves the syntactic ambiguity between the two forms
This matters as an expression
that is a name
is evaluated and represents a value while a name
by itself can be an object; we want a view conversion to be an object,
not that it really matters
This wording uses "interpreted as" rather
than "shall be" so that this rule is not used to resolve overloading;
it is solely about evaluation as described above.
In a view conversion for an untagged type, the target type shall be convertible
(back) to the operand type.
Reason: Untagged view conversions appear
only as [in] out parameters. Hence, the reverse conversion
must be legal as well. The forward conversion must be legal even for
an out parameter, because (for example) actual parameters of an
access type are always copied in anyway.
Paragraphs 9 through
20 were reorganized and moved below.
The entire Legality Rules section has been reorganized to eliminate an
unintentional incompatibility with Ada 83. In rare cases, a type conversion
between two types related by derivation is not allowed by Ada 95, while
it is allowed in Ada 83. The reorganization fixes this. Much of the wording
of the legality section is unchanged, but it is reordered and reformatted.
Because of the limitations of our tools, we had to delete and replace
nearly the entire section. The text of Ada 95 paragraphs 8 through 12,
14, 15, 17, 19, 20, and 24 are unchanged (just moved); these are now
24.1 through 24.5, 24.12, 24.13, 24.17, 24.19, 24.20, and 8.
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:
The operand type shall be covered by or descended
from the target type; or
Ramification: This is a conversion toward
the root, which is always safe.
The operand type shall be a class-wide type that covers the target type;
Ramification: This is a conversion of
a class-wide type toward the leaves, which requires a tag check. See
These two rules imply that a conversion from an ancestor type to a type
extension is not permitted, as this would require specifying the values
for additional components, in general, and changing the tag. An extension_aggregate
has to be used instead, constructing a new value, rather than converting
an existing value. However, a conversion from the class-wide type rooted
at an ancestor type is permitted; such a conversion just verifies that
the operand's tag is a descendant of the target.
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.
Ramification: We allow converting any
class-wide type T'Class to or from a class-wide interface type even if
the specific type T does not have an appropriate interface ancestor,
because some extension of T might have the needed ancestor. This is similar
to a conversion of a class-wide type toward the leaves of the tree, and
we need to be consistent. Of course, there is a run-time check that the
actual object has the needed interface.
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:
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:
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;
Reason: For unrelated array types, the
component types could have different accessibility, and we had better
not allow a conversion of a local type into a global type, in case the
local type points at local objects. We don't need a check for other types
of components; such components necessarily are for related types, and
either have the same accessibility or (for access discriminants) cannot
be changed so the discriminant check will prevent problems.
Neither the target type nor the operand type shall be limited;
Reason: We cannot allow conversions between
unrelated limited types, as they may have different representations,
and (since the types are limited), a copy cannot be made to reconcile
If the target type of a view conversion has aliased components, then
so shall the operand type; and
We cannot allow a view conversion from an object with unaliased components
to an object with aliased components, because that would effectively
allow pointers to unaliased components. This rule was missing from Ada
We cannot allow view conversions between unrelated might-be-by-reference
types, as they may have different representations, and a copy cannot
be made to reconcile the representations.
Ramification: These rules only apply
to unrelated array conversions; different (weaker) rules apply to conversions
between related types.
If the target type is universal_access
, then the operand type
shall be an access type.
Discussion: Such a conversion cannot
be written explicitly, of course, but it can be implicit (see below).
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
The Legality Rules and Dynamic
Semantics are worded so that a type_conversion
T(X) (where T is an access type) is (almost) equivalent to the attribute_reference
'Access, where the result is of type T. The only difference
is that the type_conversion
accepts a null value, whereas the attribute_reference
would raise Constraint_Error.
If the target type is an access-to-variable type, then the operand type
shall be an access-to-variable type;
Ramification: If the target type is an
access-to-constant type, then the operand type can be access-to-constant
If the target designated type is tagged, then the operand designated
type shall be convertible to the target designated type;
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 designated type shall be discriminated in its full view and unconstrained
in any partial view, and one of the designated subtypes shall be unconstrained;
This does not require that types have a partial view in order to allow
the conversion, simply that any partial view that does exist is unconstrained.
This allows conversions both ways (either subtype can be unconstrained);
while Ada 95 only allowed the conversion if the target subtype is unconstrained.
We generally want type conversions to be symmetric; which type is the
target shouldn't matter for legality.
If the visible partial view is constrained, we do not allow conversion
between unconstrained and constrained subtypes. This means that whether
the full type had discriminants is not visible to clients of the partial
We assume the worst in a generic body whether or
not a formal subtype has a constrained partial view; specifically, in
a generic body a discriminated subtype is considered to have a constrained
partial view if it is a descendant of an untagged generic formal private
or derived type (see 12.5.1 for the formal
definition of this rule).
Reason: These rules are designed to ensure
that aliased array objects only need "dope" if their
nominal subtype is unconstrained, but they can always have dope
if required by the run-time model (since no sliding is permitted as part
of access type conversion). By contrast, aliased discriminated objects
will always need their discriminants stored with them, even if
nominally constrained. (Here, we are assuming an implementation that
represents an access value as a single pointer.)
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. 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
The access parameter case is handled by a run-time check. Run-time checks
are also done in instance bodies, and for stand-alone objects of anonymous
Reason: We prohibit storing accesses
to objects deeper than a stand-alone object of an anonymous access-to-object
(even while we allow storing all other accesses) in order to prevent
If the target type is a pool-specific
access-to-object type, then the operand type shall be universal_access
Reason: This allows null to be
converted to pool-specific types. Without it, null could be converted
to general access types but not pool-specific ones, which would be too
inconsistent. Remember that these rules only apply to unrelated types,
so we don't have to talk about conversions to derived or other related
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
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 12.3), this rule applies also in
the private part of an instance of a generic unit.
If the operand
type is declared within a generic body, the target type shall be declared
within the generic body.
Reason: The reason it is illegal to convert
from an access-to-subprogram type declared in a generic body to one declared
outside that body is that in an implementation that shares generic bodies,
procedures declared inside the generic need to have a different calling
convention — they need an extra parameter pointing to the data
declared in the current instance. For procedures declared in the spec,
that's OK, because the compiler can know about them at compile time of
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
applies to all of the Legality Rules in this section. It won't
matter for the majority of these rules, but in any case that it does,
we want to apply the same recheck in the private part. (Ada got the default
wrong for these, as there is only one known case where we don't want
to recheck in the private part, see derivations without record extensions
that is a value conversion denotes the value that is the result of converting
the value of the operand to the target subtype.
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 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
the target type, if any.
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:
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.
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.
If the target
type is some other real type, then the result is within the accuracy
of the target type (see G.2
”, for implementations that support
the Numerics Annex).
Discussion: An integer type might have
more bits of precision than a real type, so on conversion (of a large
integer), some precision might be lost.
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).
This was implementation defined in Ada 83. There seems no reason to preserve
the nonportability in Ada 95. Round-away-from-zero is the conventional
definition of rounding, and standard Fortran and COBOL both specify rounding
away from zero, so for interoperability, it seems important to pick this.
This is also the most easily “undone” by hand. Round-to-nearest-even
is an alternative, but that is quite complicated if not supported by
the hardware. In any case, this operation is not usually part of an inner
loop, so predictability and portability are judged most important. A
floating point attribute function Unbiased_Rounding is provided (see
) for those applications that require
round-to-nearest-even, and a floating point attribute function Machine_Rounding
(also see A.5.3
) is provided for those applications
that require the highest possible performance. “Deterministic”
rounding is required for static conversions to integer as well. See 4.9
The result is the value of the target
type with the same position number as that of the operand value.
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.
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.
each nonnull index range, a check is made that the bounds of the range
belong to the corresponding index subtype.
Discussion: Only nonnull index ranges
are checked, per AI83-00313.
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
Ramification: This applies whether or
not the component is initialized.
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.
This check is needed for operands that are access
in instance bodies. Other cases are handled by
the legality rule given previously.
(Non-Array) Type Conversion
The value of each nondiscriminant
component of the result is that of the matching component of the operand
Ramification: This applies whether or
not the component is initialized.
[The tag of the result is that of
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.
Ramification: This check is certain to
succeed if the operand type is itself covered by or descended from the
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;
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.
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
It is a ramification of
the rules for the discriminants of derived types that each discriminant
of the result is covered either by this paragraph or the previous one.
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.
each discriminant of the result, a check is made that its value belongs
to its subtype.
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
This check is needed for operands that are access parameters, for stand-alone
anonymous access objects, and in instance bodies.
Note that this check can never fail for the
implicit conversion to the anonymous type of an access parameter that
is done when calling a subprogram with an access parameter.
Ramification: A conversion to an anonymous
access type happens implicitly as part of initializing or assigning to
an anonymous access object.
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.
Ramification: The checks are certain
to succeed if the target and operand designated subtypes statically match.
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
), a check is performed that the value
satisfies the predicates predicate
of the target subtype is satisfied for the value
The first check above is a Range_Check for scalar subtypes, a Discriminant_Check
or Index_Check for access subtypes, and a Discriminant_Check for discriminated
subtypes. The Length_Check for an array conversion is performed as part
of the conversion to the target type. The check for exclusion of null
is an Access_Check.
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;
the target type is composite, checks are performed as above for a value
The properties of this
new view are as follows:
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;
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);
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 access
type and the view conversion is passed as an out
this latter case, the value of the operand object may
used to initialize the formal
parameter without checking against any constraint of the target subtype
(as described more precisely in see
This ensures that even an out
parameter of an elementary access
type is initialized reasonably.
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” Assertions.Assertion_Error
. 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.
This definition is needed because
the semantics of various constructs involves converting to a type, whereas
an explicit type_conversion
actually converts to a subtype. For example, the evaluation of a range
is defined to convert the values of the expressions to the type of the
Ramification: A conversion to a scalar
type, or, equivalently, to an unconstrained scalar subtype, can raise
Constraint_Error if the value is outside the base range of the type.
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:
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;
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;
Otherwise, it is unspecified
whether a new object is created.
If a new object is created, then the initialization
of that object is an assignment operation.
Reason: This makes
a difference in the case of converting from an array type with unaliased
components to one with aliased components if the element type has a controlled
In addition to explicit
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.
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.
23 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
Examples of numeric
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
Incompatibilities With Ada 83
The component subtypes have to statically match
in an array conversion, rather than being checked for matching constraints
at run time.
Because sliding of array bounds is now provided
for operations where it was not in Ada 83, programs that used to raise
Constraint_Error might now continue executing and produce a reasonable
result. This is likely to fix more bugs than it creates.
Extensions to Ada 83
We no longer require type-mark conformance between
a parameter of the form of a type conversion, and the corresponding formal
parameter. This had caused some problems for inherited subprograms (since
there isn't really a type-mark for converted formals), as well as for
renamings, formal subprograms, etc. See AI83-00245, AI83-00318, AI83-00547.
We now specify “deterministic” rounding
from real to integer types when the value of the operand is exactly between
two integers (rounding is away from zero in this case).
“Sliding” of array bounds (which
is part of conversion to an array subtype) is performed in more cases
in Ada 95 than in Ada 83. Sliding is not performed on the operand of
a membership test, nor on the operand of a qualified_expression
It wouldn't make sense on a membership test, and we wish to retain a
connection between subtype membership and subtype qualification. In general,
a subtype membership test returns True if and only if a corresponding
subtype qualification succeeds without raising an exception. Other operations
that take arrays perform sliding.
Wording Changes from Ada 83
We no longer explicitly list the kinds of things
that are not allowed as the operand of a type_conversion
except in a NOTE.
The rules in this subclause subsume the rules for "parameters of
the form of a type conversion," and have been generalized to cover
the use of a type conversion as a name
Incompatibilities With Ada 95
unrelated array types that are limited or (for view conversions) might
be by-reference types are now illegal. The representations of two such
arrays may differ, making the conversions impossible. We make the check
here, because legality should not be based on representation properties.
Such conversions are likely to be rare, anyway. There is a potential
that this change would make a working program illegal (if the types have
the same representation).
If a discriminated full type has a partial view (private type) that is
constrained, we do not allow conversion between access-to-unconstrained
and access-to-constrained subtypes designating the type. Ada 95 allowed
this conversion and the declaration of various access subtypes, requiring
that the designated object be constrained and thus making details of
the implementation of the private type visible to the client of the private
type. See 4.8
for more on this topic.
Extensions to Ada 95
Conversion rules for universal_access
defined. These allow the use of anonymous access values in equality tests
), and also allow the use of null
in type conversions and other contexts that do not provide a single expected
A type conversion from an access-to-discriminated and unconstrained object
to an access-to-discriminated and constrained one is allowed. Ada 95
only allowed the reverse conversion, which was weird and asymmetric.
Of course, a constraint check will be performed for this conversion.
Wording Changes from Ada 95
Wording was added to ensure that view conversions
are constrained, and that a tagged view conversion has a tagged object.
Both rules are needed to avoid having a way to change the discriminants
of a constrained object.
Wording was added to ensure that the aliased status
of array components cannot change in a view conversion. This rule was
needed to avoid having a way to change the discriminants of an aliased
object. This rule was repealed later, as Ada 2005 allows changing the
discriminants of an aliased object.
The organization of the legality rules was changed, both to make it clearer,
and to eliminate an unintentional incompatibility with Ada 83. The old
organization prevented type conversions between some types that were
related by derivation (which Ada 83 always allowed).
Clarified that an untagged type conversion appearing as a generic actual
parameter for a generic in out
formal parameter is not a view
conversion (and thus is illegal). This confirms the ACATS tests, so all
implementations already follow this interpretation.
Rules added by the Corrigendum to eliminate problems with discriminants
of aliased components changing were removed, as we now generally allow
discriminants of aliased components to be changed.
Accessibility checks on conversions involving types with anonymous access
components were added. These components have the level of the type, and
conversions can be between types at different levels, which could cause
dangling access values in the absence of such checks.
Inconsistencies With Ada 2005
A stand-alone object of an anonymous access-to-object
type now has dynamic accessibility. Normally, this will make programs
legal that were illegal in Ada 2005. However, it is possible that a program
that previously raised Program_Error now will not. It is very unlikely
that an existing program intentionally depends on the exception being
raised; the change is more likely to fix bugs than introduce them.
Wording Changes from Ada 2005
Clarified that a root numeric type is not considered
a common ancestor for a conversion.
Incompatibilities With Ada 2012
Corrigendum: Because of a rule added in
12.5.1, the checks for the legality of an
access type conversion in a generic body were strengthened to use an
assume the worst rule. This case is rather unlikely as a formal private
or derived type with discriminants is required along with a conversion
between two access types whose designated types don't statically match,
and any such programs were at risk having objects disappear while valid
access values still pointed at them.
Wording Changes from Ada 2012
Corrigendum: Moved the generic boilerplate
so that it covers all Legality Rules in this subclause. This was always
intended, but it is not expected to change anything other than conversions
between unrelated arrays.
Corrigendum: Added a formal definition of
the copy potentially created by a value conversion of a composite type,
so properties like finalization and accessibility are properly defined.
This model was always intended and expected (else 13.6
would not work), but it was not previously formally defined.
Corrigendum: Updated wording of type conversions
to use the new term "satisfies the predicates" (see 3.2.4).
Corrigendum: Clarified the wording describing
the effect of view conversions of out parameters such that it
is clear that the detailed effect is defined in 6.4.1,
Corrigendum: Updated wording of type conversions
so that the exception raise or other effect of a failed predicate check
is as defined in 3.2.4; we don't want to
repeat those rules here. This doesn't change the behavior for predicate
checks possible in original Ada 2012, only ones using the new aspect
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe