6.3.1 Conformance Rules
subprogram profiles are given in more than one place, they are required
to conform in one of four ways: type conformance, mode conformance, subtype
conformance, or full conformance.]
[As explained in B.1
”, a convention
can be specified for an entity.] Unless this document states otherwise,
the default convention of an entity is Ada. [For a callable entity or
access-to-subprogram type, the convention is called the calling convention
The following conventions are defined by the language:
The default calling convention
for any subprogram not listed below is Ada
. [The Convention aspect
may be specified to override the default calling convention (see B.1
See also the rule about
renamings-as-body in 8.5.4
calling convention represents subprograms that are “built
in” to the compiler. The default calling convention is Intrinsic
for the following:
an enumeration literal;
a "/=" operator declared
implicitly due to the declaration of "=" (see 6.6
any other implicitly declared subprogram
unless it is a dispatching operation of a tagged type;
an inherited subprogram of a generic
formal tagged type with unknown discriminants;
package P is
type Root is tagged null record;
procedure Proc(X: Root);
type Formal(<>) is new Root with private;
package G is
package body G is
X: Formal := ...;
Proc(X); -- This is a dispatching call in Instance, because
-- the actual type for Formal is class-wide.
-- Proc'Access would be illegal here, because it is of
-- convention Intrinsic, by the above rule.
type Actual is new Root with ...;
procedure Proc(X: Actual);
package Instance is new G(Formal => Actual'Class);
-- It is legal to pass in a class-wide actual, because Formal
-- has unknown discriminants.
Within Instance, all calls to Proc will be dispatching
calls, so Proc doesn't really exist in machine code, so we wish to avoid
taking 'Access of it. This rule applies to those cases where the actual
type might be class-wide, and makes these Intrinsic, thus forbidding
an attribute that is a subprogram;
The profile of a prefixed view is different from than
the “real” profile of the subprogram (it doesn't have the
first parameter), so we don't want to be able to take 'Access of it,
as that would require generating a wrapper of some sort.
We except prefixed views that have synchronization
kind By_Protected_Procedure so that they can be used with an access-to-protected-procedure
type. These don't require special wrappers (this is the normal form for
a protected subprogram call). The By_Entry part is just for consistency
(there is no access-to-entry type in Ada).
[The Access attribute is not allowed for
Ramification: The Intrinsic calling convention
really represents any number of calling conventions at the machine code
level; the compiler might have a different instruction sequence for each
intrinsic. That's why the Access attribute is disallowed. We do not wish
to require the implementation to generate an out of line body for an
Whenever we wish to disallow the Access attribute in order to ease implementation,
we make the subprogram Intrinsic. Several language-defined subprograms
Convention => Intrinsic;”. An implementation
might actually implement this as “with
Import => True,
Convention => Intrinsic;”, if there is really no body, and the
implementation of the subprogram is built into the code generator.
Subprograms declared in protected_bodies
will generally have a special calling convention so as to pass along
the identification of the current instance of the protected type. The
convention is not protected since such local subprograms need
not contain any “locking” logic since they are not callable
via “external” calls; this rule prevents an access value
designating such a subprogram from being passed outside the protected
The “implicitly declared subprogram”
above refers to predefined operators (other than the "=" of
a tagged type) and the inherited subprograms of untagged types.
The default calling convention
for a protected subprogram, for a prefixed view of a subprogram with a synchronization kind of By_Protected_Procedure,
and for an access-to-subprogram type with the reserved word protected
in its definition.
The default calling convention
for an entry and for a prefixed
view of a subprogram with a synchronization kind of By_Entry
The calling convention for an anonymous access-to-subprogram parameter
or anonymous access-to-subprogram result is protected
if the reserved
appears in its definition; otherwise, it is the
convention of the entity subprogram
that has contains
the parameter or result, unless that entity has
convention protected, entry, or Intrinsic, in which case
the convention is Ada
Ramification: The calling convention
for other anonymous access-to-subprogram types is Ada.
[If not specified above as Intrinsic, the calling convention for any
inherited or overriding dispatching operation of a tagged type is that
of the corresponding subprogram of the parent type.] The default calling
convention for a new dispatching operation of a tagged type is the convention
of the type.
The first rule is officially
stated in 3.9.2
. The second is intended to
make interfacing to foreign OOP languages easier, by making the default
be that the type and operations all have the same convention.
Of these four conventions, only Ada and Intrinsic are allowed as a convention_identifier
in the specification of a Convention aspect.
The names of the protected
cannot be used in the specification of Convention. Note that protected
are reserved words.
Two profiles are type conformant
if they have the same number of parameters, and both have a result if
either does, and corresponding parameter and result types are the same,
or, for access parameters or access results, corresponding designated
types are the same, or corresponding designated profiles are type conformant.
For anonymous access-to-object parameters, the designated types have
to be the same for type conformance, not the access types, since in general
each access parameter has its own anonymous access type, created when
the subprogram is called. Of course, corresponding parameters have to
be either both access parameters or both not access parameters.
Similarly, for anonymous access-to-subprogram parameters, the designated
profiles of the types, not the types themselves, have to be conformant.
corresponding parameters have identical modes and both or neither are
explicitly aliased parameters; and
for corresponding access parameters and any access result type, the designated
subtypes statically match and either both or neither are access-to-constant,
or the designated profiles are subtype conformant.
Two profiles are subtype conformant
if they are mode conformant, corresponding subtypes of the profile statically
match, and the associated calling conventions are the same. The profile
of a generic formal subprogram is not subtype conformant with any other
Two profiles are fully conformant
if they are subtype conformant, if they have access-to-subprogram results
whose designated profiles are fully conformant, and for corresponding
for access-to-subprogram parameters, the designated profiles are fully
Ramification: Full conformance requires
subtype conformance, which requires the same calling conventions. However,
the calling convention of the declaration and body of a subprogram or
entry are always the same by definition.
The part about null_exclusion
is necessary to prevent controlling parameters from having different
exclusions, as such a parameter is defined to exclude null whether or
not an exclusion is given.
The parts about access-to-subprogram parameters and results is necessary
to prevent such types from having different default_expression
in the specification and body of a subprogram. If that was allowed, it
would be undefined which default_expression
was used in a call of an access-to-subprogram parameter.
expressions are fully conformant
if, [after replacing each use
of an operator with the equivalent function_call
each constituent construct of one corresponds to
an instance of the same syntactic category in the other, except that
an expanded name may correspond to a direct_name
or to a different expanded name in the other; and
Note that it doesn't say “respectively” because a direct_name
can correspond to a selector_name
and vice -
by the previous bullet. This rule allows the prefix
of an expanded name to be removed, or replaced with a different prefix
that denotes a renaming of the same entity. However, it does not allow
to be replaced with one denoting a distinct renaming (except for direct_name
of expanded names). Note that calls using operator notation are equivalent
to calls using prefix notation.
Given the following
package A is
function F(X : Integer := 1) return Boolean;
F_View(X : Integer := 9999) return
with A, B; use A, B;
procedure Main is ...
Within Main, the expressions “F”,
“A.F”, “B.A_View.F”, and “A_View.F”
are all fully conformant with one another. However, “F” and
“F_View” are not fully conformant. If they were, it would
be bad news, since the two denoted views have different default_expression
that is a literal in one is a user-defined literal
if and only if the corresponding literal in the other is also a user-defined
literal. Furthermore, if neither are user-defined literals then they
shall have the same values[, but they may have differing textual representations];
if both are user-defined literals then they shall have the same textual
representation has the same value as the
corresponding literal in the other
This rule applies to character_literals,
so even though other rules would allow a rename of a character literal
to conform to the literal, this rule prevents that The
literals may be written differently
Ramification: Note that the above definition
makes full conformance a transitive relation.
are fully conformant
if they have the same number of discriminants,
and discriminants in the same positions have the same names, statically
matching subtypes, and default_expression
that are fully conformant with one another.
The prefixed view profile
of a subprogram
is the profile obtained by omitting the first parameter of that subprogram.
There is no prefixed view profile for a parameterless subprogram. For
the purposes of defining subtype and mode conformance, the convention
of a prefixed view profile is considered to match that of either an entry
or a protected operation.
This definition is used to
define how primitive subprograms of interfaces match operations in task
and protected type definitions (see 9.1
Reason: The weird rule about conventions
is pretty much required for synchronized interfaces to make any sense.
There will be wrappers all over the place for interfaces anyway. Of course,
this doesn't imply that entries have the same convention as protected
An implementation may declare an operator declared
in a language-defined library unit to be intrinsic.
Extensions to Ada 83
The rules for full conformance
are relaxed — they are now based on the structure of constructs,
rather than the sequence of lexical elements. This implies, for example,
that "(X, Y: T)" conforms fully with "(X: T; Y: T)",
and "(X: T)" conforms fully with "(X: in
Wording Changes from Ada 95
Clarified that the default convention is Ada. Also
clarified that the convention of a primitive operation of a tagged type
is the same as that of the type.
Defined the conformance of anonymous access-to-subprogram parameters.
Incompatibilities With Ada 2005
Now require null_exclusion
to match for full conformance. While this is technically incompatible
with Ada 2005 as defined by Amendment 1, it is a new Ada 2005 feature
and it is unlikely that users have been intentionally taking advantage
of the ability to write mismatching exclusions. In any case, it is easy
to fix: add a null_exclusion
where needed for conformance.
Now require full conformance of anonymous access-to-subprogram
parameters and results for full conformance. This is necessary so that
there is no confusion about the default expression that is used for a
call. While this is technically incompatible with Ada 2005 as defined
by Amendment 1, it is a new Ada 2005 feature and it is unlikely that
users have been intentionally taking advantage and writing different
default expressions. In any case, it is easy to fix: change any default
expressions that don't conform so that they do conform.
Now include the presence or absence of constant
in access parameters to be considered when checking mode conformance.
This is necessary to prevent modification of constants. While this is
technically incompatible with Ada 2005 as defined by Amendment 1, it
is a new Ada 2005 feature and it is unlikely that users have been intentionally
taking advantage and writing mismatching access types.
Wording Changes from Ada 2005
Explicitly aliased parameters are included as part of mode conformance
(since it affects the parameter passing mechanism).
Incompatibilities With Ada 2012
Correction: The convention
of an anonymous access-to-subprogram parameter of a protected entry or
subprogram is Ada; if one wants it to be protected it can be declared
with the keyword protected. This is incompatible, but only in
a very rare case; usually the intent is to pass a normal subprogram to
a protected subprogram (and this was impossible in Ada 2012).
Extensions to Ada 2012
Corrigendum: We now
define that a prefixed view of a subprogram with synchronization kind
By_Protected_Procedure can be used as the prefix of 'Access for an access-to-protected
type. We consider this a correction as it certainly appears that it ought
to work, but in original Ada 2012 it would have had a convention mismatch.
Wording Changes from Ada 2012
Corrigendum: We now define how two expressions
containing quantified expressions can fully conform. This isn't incompatible,
as the original Ada 2012 never allowed such expressions to conform (the
declarations in each formally being different). Neither is it an extension
as one would expect these to conform.
The conformance of literals is tightened up to
not assume anything about the value of a user-defined literal.
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe