3.9.2 Dispatching Operations of Tagged Types
primitive subprograms of a tagged type, the subprograms declared by formal_abstract_subprogram_declaration
the subprograms identified by the user-defined
literal aspects of a specific tagged type (see 4.2.1),
and the stream attributes of a specific tagged type that are available
) at the end of the declaration
list where the type is declared are called dispatching operations
[A dispatching operation can be called using a statically determined
tag, in which case the body to be executed is determined
at compile time. Alternatively, the controlling tag can be dynamically
determined, in which case the call dispatches
to a body that is
determined at run time;] such a call is termed a dispatching call
[As explained below, the properties of the operands and the context of
a particular call on a dispatching operation determine how the controlling
tag is determined, and hence whether or not the call is a dispatching
call. Run-time polymorphism is achieved when a dispatching operation
is called by a dispatching call.]
For the stream attributes of a type declared immediately within a package_specification
that has a partial view, the declaration list to consider is the visible
part of the package. Stream attributes that are not available in the
same declaration list are not dispatching as there is no guarantee that
descendants of the type have available attributes (there is such a guarantee
for visibly available attributes). If we allowed dispatching for any
available attribute, then for attributes defined in the private part
we could end up executing a nonexistent body.
Language Design Principles
The controlling tag determination rules are
analogous to the overload resolution rules, except they deal with run-time
type identification (tags) rather than compile-time type resolution.
As with overload resolution, controlling tag determination may depend
on operands or result context.
A call on a dispatching operation
is a call whose name
denotes the declaration of a dispatching operation.
in a call on a dispatching operation of a
tagged type T
is one whose corresponding formal parameter is of
or is of an anonymous access type with designated type
the corresponding formal parameter is called
a controlling formal parameter
. If the controlling formal parameter
is an access parameter, the controlling operand is the object designated
by the actual parameter, rather than the actual parameter itself.
the call is to a (primitive) function with result type T
with a controlling result
), then the call has a controlling result
— the context of the call can control the dispatching. Similarly,
if the call is to a function with an access result type designating T
(a function with a controlling access result
), then the call has
a controlling access result
, and the context can similarly control
This definition implies
that a call through the dereference of an access-to-subprogram value
is never considered a call on a dispatching operation. Note also that
if the prefix
denotes a renaming_declaration
the place where the renaming occurs determines whether it is primitive;
the thing being renamed is irrelevant.
expression of a tagged type is either statically
tagged, or tag indeterminate
, according to whether, when used
as a controlling operand, the tag that controls dispatching is determined
statically by the operand's (specific) type, dynamically by its tag at
run time, or from context. A qualified_expression
or parenthesized expression is statically, dynamically, or indeterminately
tagged according to its operand. A conditional_expression
is statically, dynamically, or indeterminately tagged according to rules
given in 4.5.7. A declare_expression
is statically, dynamically, or indeterminately tagged according to its
For other kinds of name
and expressions, this is determined as follows:
or expression is statically tagged
if it is of a specific tagged
type and, if it is a call with a controlling result or controlling access
result, it has at least one statically tagged controlling operand;
Discussion: It is illegal to have both
statically tagged and dynamically tagged controlling operands in the
same call -- see below.
or expression is dynamically tagged
if it is of a class-wide type,
or it is a call with a controlling result or controlling access result
and at least one dynamically tagged controlling operand;
or expression is tag indeterminate
if it is a call with a controlling
result or controlling access result, all of whose controlling operands
(if any) are tag indeterminate.
is statically or dynamically tagged according to whether the type determined
by the subtype_mark
is specific or class-wide, respectively.] For an object that is designated
by an expression whose expected type is an anonymous access-to-specific
tagged type, the object is dynamically tagged if the expression, ignoring
enclosing parentheses, is of the form X'Access, where X is of a class-wide
type, or is of the form new
T'(...), where T denotes a class-wide
subtype. Otherwise, the object is statically or dynamically tagged according
to whether the designated type of the type of the expression is specific
or class-wide, respectively.
is never tag indeterminate, even if its operand is. A designated object
is never tag indeterminate.
Allocators and access attributes of class-wide types can be used as the
controlling parameters of dispatching calls.
A call on a dispatching operation shall not have
both dynamically tagged and statically tagged controlling operands.
Reason: This restriction is intended
to minimize confusion between whether the dynamically tagged operands
are implicitly converted to, or tag checked against the specific type
of the statically tagged operand(s).
If the expected type for an expression or name
is some specific tagged type, then the expression or name
shall not be dynamically tagged unless it is a controlling operand in
a call on a dispatching operation. Similarly, if the expected type for
an expression is an anonymous access-to-specific tagged type, then the
object designated by the expression shall not be dynamically tagged unless
it is a controlling operand in a call on a dispatching operation.
Reason: This prevents implicit "truncation"
of a dynamically-tagged value to the specific type of the target object/formal.
An explicit conversion is required to request this truncation.
This rule applies to all expressions or name
with a specific expected type, not just those that are actual parameters
to a dispatching call. This rule does not apply to a membership test
whose tested_simple_expression expression
is class-wide, since any type that covers the tested type is explicitly
allowed. See 4.5.2
. This rule also doesn't
apply to a selected_component
is a subprogram, since the rules explicitly say that the prefix may be
class-wide (see 4.1.3
In the declaration of a dispatching operation of a tagged type, everywhere
a subtype of the tagged type appears as a subtype of the profile (see
), it shall statically match the first subtype
of the tagged type.
If the dispatching operation
overrides an inherited subprogram, it shall be subtype conformant with
the inherited subprogram.
The convention of an inherited
dispatching operation is the convention of the corresponding primitive
operation of the parent or progenitor type. The default convention of
a dispatching operation that overrides an inherited primitive operation
is the convention of the inherited operation; if the operation overrides
multiple inherited operations, then they shall all have the same convention.
An explicitly declared dispatching operation shall not be of convention
Reason: These rules ensure that constraint
checks can be performed by the caller in a dispatching call, and parameter
passing conventions match up properly. A special rule on aggregates prevents
values of a tagged type from being created that are outside of its first
This rule ensures that the default_expression
always produces the "correct" tag when called with or without
dispatching, or when inherited by a descendant. If it were statically
tagged, the default would be useless for a dispatching call; if it were
dynamically tagged, the default would be useless for a nondispatching
If a dispatching operation is defined by a subprogram_renaming_declaration
or the instantiation of a generic subprogram, any access parameter of
the renamed subprogram or the generic subprogram that corresponds to
a controlling access parameter of the dispatching operation, shall have
a subtype that excludes null.
A given subprogram shall not be a dispatching operation
of two or more distinct tagged types.
Reason: This restriction minimizes confusion
since multiple dispatching is not provided. The normal solution is to
replace all but one of the tagged types with their class-wide types.
This restriction applies even if the partial view (see 7.3
of one or both of the types is untagged. This follows from the definition
of dispatching operation: the operation is a dispatching operation anywhere
the full views of the (tagged) types are visible.
The explicit declaration of a primitive subprogram
of a tagged type shall occur before the type is frozen (see 13.14
[For example, new dispatching operations cannot be added after objects
or values of the type exist, nor after deriving a record extension from
it, nor after a body.]
This rule is needed because (1) we don't want people dispatching to things
that haven't been declared yet, and (2) we want to allow the static part
of tagged type descriptors to be static (allocated statically, and initialized
to link-time-known symbols). Suppose T2 inherits primitive P from T1,
and then overrides P. Suppose P is called before
of the overriding P. What should it dispatch to? If the answer is the
new P, we've violated the first principle above. If the answer is the
old P, we've violated the second principle. (A call to the new one necessarily
raises Program_Error, but that's beside the point.)
Note that a call upon a dispatching operation
of type T will freeze T.
We considered applying this rule to all derived
types, for uniformity. However, that would be upward incompatible, so
we rejected the idea. As in Ada 83, for an untagged type, the above call
upon P will call the old P (which is arguably confusing).
Because of this rule, the type descriptor can be created (presumably
containing linker symbols pointing at the not-yet-compiled bodies) at
the first freezing point of the type. It also prevents, for a (nonincomplete)
tagged type declared in a package_specification
overriding in the body or by a child subprogram.
To be honest:
This rule applies only to "original" declarations and not to
the completion of a primitive subprogram, even though a completion is
technically an explicit declaration, and it may declare a primitive subprogram.
the execution of a call on a dispatching operation of a type T
the controlling tag value
determines which subprogram body is
executed. The controlling tag value is defined as follows:
If one or more controlling
operands are statically tagged, then the controlling tag value is statically
to be the tag of T
If one or more controlling operands are dynamically
tagged, then the controlling tag value is not statically determined,
but is rather determined by the tags of the controlling operands.
there is more than one dynamically tagged controlling operand, a check
is made that they all have the same tag.
check fails, Constraint_Error is raised unless the call is a function_call
denotes the declaration of an equality operator (predefined or user defined)
that returns Boolean, in which case the result of the call is defined
to indicate inequality, and no subprogram_body
is executed. This check is performed prior to evaluating any tag-indeterminate
Reason: Tag mismatch is considered an
error (except for "=" and "/=") since the corresponding
primitive subprograms in each specific type expect all controlling operands
to be of the same type. For tag mismatch with an equality operator, rather
than raising an exception, "=" returns False and "/="
returns True. No equality operator is actually invoked, since there is
no common tag value to control the dispatch. Equality is a special case
to be consistent with the existing Ada 83 principle that equality comparisons,
even between objects with different constraints, never raise Constraint_Error.
If all of the controlling operands (if any) are tag-indeterminate, then:
If the call has a controlling result or controlling access result and
is itself, or designates, a (possibly parenthesized or qualified) controlling
operand of an enclosing call on a dispatching operation of a descendant
of type T
, then its controlling tag value is determined by the
controlling tag value of this enclosing call;
For code that a user can write explicitly, the only contexts that can
control dispatching of a function with a controlling result of type T
are those that involve controlling operands of the same type T: if the
two types differ there is an illegality and the dynamic semantics are
In the case of an inherited subprogram however,
if a default expression is a function call, it may be of type T while
the parameter is of a type derived from T. To cover this case, we talk
about "a descendant of T" above. This is safe, because if the
type of the parameter is descended from the type of the function result,
it is guaranteed to inherit or override the function, and this ensures
that there will be an appropriate body to dispatch to. Note that abstract
functions are not an issue here because the call to the function is a
dispatching call, so it is guaranteed to always land on a concrete body.
If the call has a controlling result or controlling access result and
(possibly parenthesized, qualified, or dereferenced) is the expression
of an assignment_statement
whose target is of a class-wide type, then its controlling tag value
is determined by the target;
controlling tag value is statically determined to be the tag of type
This includes the cases
of a tag-indeterminate procedure call, and a tag-indeterminate function_call
that is used to initialize a class-wide formal parameter or class-wide
For the execution of a call on a dispatching operation, the action performed
is determined by the properties of the corresponding dispatching operation
of the specific type identified by the controlling tag value:
if the corresponding operation is explicitly declared for this type,
[even if the declaration occurs in a private part], then the action comprises
an invocation of the explicit body for the operation;
if the corresponding operation is implicitly declared for this type and
is implemented by an entry or protected subprogram (see 9.1
), then the action comprises a call
on this entry or protected subprogram, with the target object being given
by the first actual parameter of the call, and the actual parameters
of the entry or protected subprogram being given by the remaining actual
parameters of the call, if any;
if the corresponding operation is a predefined operator then the action
comprises an invocation of that operator;
otherwise, the action is the same as the action for the corresponding
operation of the parent type or progenitor type from which the operation
was inherited except that additional invariant checks (see 7.3.2
and class-wide postcondition checks (see 6.1.1
may apply. If there is more than one such corresponding operation, the
action is that for the operation that is not a null procedure, if any;
otherwise, the action is that of an arbitrary one of the operations.
“Corresponding dispatching operation” refers to the inheritance
relationship between subprograms. Primitive operations are always inherited
for a type T, but they might not be declared if the primitive operation
is never visible within the immediate scope of the type T. If no corresponding
operation is declared, the last bullet is used and the corresponding
operation of the parent type is executed (an explicit body that happens
to have the same name and profile is not called in that case).
We have to talk about progenitors in the last bullet in case the corresponding
operation is a null procedure inherited from an interface. In that case,
the parent type might not even have the operation in question.
For the last bullet, if there are multiple corresponding operations for
the parent and progenitors, all but one of them have to be a null procedure.
(If the progenitors declared abstract routines, there would have to be
an explicit overriding of the operation, and then the first bullet would
apply.) We call the nonnull routine if one exists.
Any explicit declaration for an inherited corresponding operation has
to be an overriding routine. These rules mean that a dispatching call
executes the overriding routine (if any) for the specific type.
The wording of the above rules is intended to ensure that the same body
is executed for a given tag, whether that tag is determined statically
or dynamically. For a type declared in a package, it doesn't matter whether
a given subprogram is overridden in the visible part or the private part,
and it doesn't matter whether the call is inside or outside the package.
package P1 is
type T1 is tagged null record;
procedure Op_A(Arg : in T1);
procedure Op_B(Arg : in T1);
with P1; use P1;
package P2 is
type T2 is new T1 with null record;
procedure Op_A(Param : in T2);
procedure Op_B(Param : in T2);
with P1; with P2;
procedure Main is
X : P2.T2;
Y : P1.T1'Class := X;
P2.Op_A(Param => X); -- Nondispatching call to a dispatching operation.
P1.Op_A(Arg => Y); -- Dispatching call.
P2.Op_B(Arg => X); -- Nondispatching call to a dispatching operation.
P1.Op_B(Arg => Y); -- Dispatching call.
The two calls to Op_A both execute the body
of Op_A that has to occur in the body of package P2. Similarly, the two
calls to Op_B both execute the body of Op_B that has to occur in the
body of package P2, even though Op_B is overridden in the private part
of P2. Note, however, that the formal parameter names are different for
P2.Op_A versus P2.Op_B. The overriding declaration for P2.Op_B is not
visible in Main, so the name in the call actually denotes the implicit
declaration of Op_B inherited from T1.
If a call occurs in the program text before
an overriding, which can happen only if the call is part of a default
expression, the overriding will still take effect for that call.
Implementation Note: Even when a tag
is not statically determined, a compiler might still be able to
figure it out and thereby avoid the overhead of run-time dispatching.
78 The body to be executed for a call on
a dispatching operation is determined by the tag; it does not matter
whether that tag is determined statically or dynamically, and it does
not matter whether the subprogram's declaration is visible at the place
of the call.
This subclause covers calls on dispatching subprograms of a tagged type.
Rules for tagged type membership tests are described in 4.5.2
Controlling tag determination for an assignment_statement
is described in 5.2
80 A dispatching call can dispatch to a
body whose declaration is not visible at the place of the call.
81 A call through an access-to-subprogram
value is never a dispatching call, even if the access value designates
a dispatching operation. Similarly a call whose prefix
denotes a subprogram_renaming_declaration
cannot be a dispatching call unless the renaming itself is the declaration
of a primitive subprogram.
Extensions to Ada 83
The concept of dispatching
operations is new.
Incompatibilities With Ada 95
If a dispatching operation is defined by a subprogram_renaming_declaration
and it has a controlling access parameter, Ada 2005 requires the subtype
of the parameter to exclude null. The same applies to instantiations.
This is required so that all calls to the subprogram operate the same
way (controlling access parameters have to exclude null so that dispatching
calls will work). Since Ada 95 didn't have the notion of access subtypes
that exclude null, and all access parameters excluded null, it had no
such rules. These rules will require the addition of an explicit not
on nondispatching operations that are later renamed to be dispatching,
or on a generic that is used to define a dispatching operation.
Extensions to Ada 95
Functions that have an access result type can be
dispatching in the same way as a function that returns a tagged object
Wording Changes from Ada 95
Allocators and access attributes of objects of class-wide
types can be used as the controlling parameter in a dispatching calls.
This was an oversight in the definition of Ada 95. (See 3.10.2
Corrected the conventions of dispatching operations.
This is extended in Ada 2005 to cover operations inherited from progenitors,
and to ensure that the conventions of all inherited operations are the
Clarified the wording to ensure that functions with no controlling operands
are tag-indeterminate, and to describe that the controlling tag can come
from the target of an assignment_statement
Fixed the wording to cover default expressions inherited by derived subprograms.
A literal reading of the old wording would have implied that operations
would be called with objects of the wrong type.
Dispatching calls include operations implemented by entries and protected
operations, so we have to update the wording to reflect that.
A stream attribute of a tagged type is usually a dispatching operation,
even though it is not a primitive operation. If they weren't dispatching,
T'Class'Input and T'Class'Output wouldn't work.
Wording Changes from Ada 2005
Defined “function with a controlling result”,
as it is used in 3.9.3
Corrected holes in the definition of dynamic dispatching:
the behavior for operations that are never declared and/or inherited
from a progenitor were not specified.
Wording Changes from Ada 2012
Added wording to clarify that user-defined literals
are dispatching operations. User-defined literal aspects follow the model
of stream-oriented attributes, and thus need to be mentioned in the same
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe