4.7 Qualified Expressions
Syntax
Name Resolution Rules
{
AI12-0325-1}
The
expected type for the operand
(the
expression
or
aggregate)
is shall resolve to
be of the type determined by the
subtype_mark,
or a universal type that covers it.
Furthermore,
the operand shall resolve to be either the specified expected type or
a universal type that covers it. Reason: {
AI12-0325-1}
The first sentence defines the expected type for
rules that assume one is defined. The second sentence prevents the use
of the various implicit conversions that are usually allowed for expected
types (except the one for numeric literals). The intent is that a qualified
expression is similar to an assertion about the subtype of the operand,
and thus implicit conversions would interfere with that intent.
Static Semantics
Dynamic Semantics
{
AI12-0100-1}
{
AI12-0449-1}
The
evaluation of a
qualified_expression
evaluates the operand (and if of a universal type, converts it to the
type determined by the
subtype_mark)
and checks that its value belongs to the subtype denoted by the
subtype_mark.
The exception Constraint_Error
is raised if this check fails.
Furthermore, if
predicate checks are enabled for the subtype denoted by the subtype_mark,
a check is performed as defined in 3.2.4 subclause
3.2.4, “Subtype
Predicates” that the value
satifies the predicates of the subtype. Ramification: This is one of the few
contexts in Ada 95 where implicit subtype conversion is not performed
prior to a constraint check, and hence no “sliding” of array
bounds is provided.
{
AI12-0100-1}
The effect of a failed predicate check is as defined
in 3.2.4; such a check could raise any exception,
not just Constraint_Error or Assertion_Error. Reason: Implicit subtype conversion is
not provided because a
qualified_expression
with a constrained target subtype is essentially an assertion about the
subtype of the operand, rather than a request for conversion. An explicit
type_conversion
can be used rather than a
qualified_expression
if subtype conversion is desired.
NOTE {
AI12-0440-1}
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
can might
be necessary to qualify the operand to resolve its type.
Examples
Examples of disambiguating
expressions using qualification:
type Mask is (Fix, Dec, Exp, Signif);
type Code is (Fix, Cla, Dec, Tnz, Sub);
Print (Mask'(Dec)); -- Dec is of type Mask
Print (Code'(Dec)); -- Dec is of type Code
{
AI12-0442-1}
for J
in Code'(Fix) .. Code'(Dec)
loop ...
-- qualification is necessary 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 DecDozen'(1 | 3 | 5 | 7 => 2,
others => 0)
-- see 4.6 Wording Changes from Ada 2005
Inconsistencies With Ada 2012
{
AI12-0100-1}
{
AI12-0005-1}
Corrigendum: A qualified_expression
now performs a predicate check for the named subtype (if it is enabled).
Original Ada 2012 did not include that check (an omission). While this
is formally inconsistent (an exception could be raised when none would
be raised by original Ada 2012), cases where when this scenario arises could
be the case are likely to be rare
(the qualified expression would have to have a stricter subtype than
the following usage) and the check is more likely to detect bugs than
be unexpected. Wording Changes from Ada 2012
{
AI12-0325-1}
Reworded the resolution rule so that the operand
of a qualified_expression
has an expected type. This eliminates an annoying inconsistency in the
language definition.
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe
