Section 6: Subprograms
1 {subprogram} {procedure} {function} A subprogram is a program unit or
intrinsic operation whose execution is invoked by a subprogram call. There are
two forms of subprogram: procedures and functions. A procedure call is a
statement; a function call is an expression and returns a value. The
definition of a subprogram can be given in two parts: a subprogram declaration
defining its interface, and a subprogram_body defining its execution.
[Operators and enumeration literals are functions.]
1.a To be honest: A function call is an expression, but more
specifically it is a name.
1.b/2 Glossary entry: {Subprogram} A subprogram is a section of a
program that can be executed in various contexts. It is invoked by
a subprogram call that may qualify the effect of the subprogram
through the passing of parameters. There are two forms of
subprograms: functions, which return values, and procedures, which
do not.
1.c/2 Glossary entry: {Function} A function is a form of subprogram that
returns a result and can be called as part of an expression.
1.d/2 Glossary entry: {Procedure} A procedure is a form of subprogram
that does not return a result and can only be called by a
statement.
2 {callable entity} A callable entity is a subprogram or entry (see Section
9). {call} A callable entity is invoked by a call; that is, a subprogram call
or entry call. {callable construct} A callable construct is a construct that
defines the action of a call upon a callable entity: a subprogram_body,
entry_body, or accept_statement.
2.a Ramification: Note that "callable entity" includes predefined
operators, enumeration literals, and abstract subprograms. "
Call" includes calls of these things. They do not have callable
constructs, since they don't have completions.
6.1 Subprogram Declarations
1 [A subprogram_declaration declares a procedure or function.]
Syntax
2/2 {AI95-00218-03} subprogram_declaration ::=
[overriding_indicator]
subprogram_specification;
3/2 This paragraph was deleted.{AI95-00348-01}
4/2 {AI95-00348-01} subprogram_specification ::=
procedure_specification
| function_specification
4.1/2 {AI95-00348-01} procedure_specification ::=
procedure defining_program_unit_name parameter_profile
4.2/2 {AI95-00348-01} function_specification ::=
function defining_designator parameter_and_result_profile
5 designator ::= [parent_unit_name . ]identifier | operator_symbol
6 defining_designator ::= defining_program_unit_name
| defining_operator_symbol
7 defining_program_unit_name ::= [parent_unit_name
. ]defining_identifier
8 [The optional parent_unit_name is only allowed for library units (see
10.1.1).]
9 operator_symbol ::= string_literal
10/2 {AI95-00395-01} The sequence of characters in an operator_symbol shall
form a reserved word, a delimiter, or compound delimiter that
corresponds to an operator belonging to one of the six categories of
operators defined in clause 4.5.
10.a/2 Reason: {AI95-00395-01} The `sequence of characters" of the string
literal of the operator is a technical term (see 2.6), and does
not include the surrounding quote characters. As defined in 2.2,
lexical elements are "formed" from a sequence of characters.
Spaces are not allowed, and upper and lower case is not
significant. See 2.2 and 2.9 for rules related to the use of
other_format characters in delimiters and reserved words.
11 defining_operator_symbol ::= operator_symbol
12 parameter_profile ::= [formal_part]
13/2 {AI95-00231-01} {AI95-00318-02} parameter_and_result_profile ::=
[formal_part] return [null_exclusion] subtype_mark
| [formal_part] return access_definition
14 formal_part ::=
(parameter_specification {; parameter_specification})
15/2 {AI95-00231-01} parameter_specification ::=
defining_identifier_list : mode [null_exclusion] subtype_mark
[:= default_expression]
| defining_identifier_list : access_definition
[:= default_expression]
16 mode ::= [in] | in out | out
Name Resolution Rules
17 {formal parameter (of a subprogram)} A formal parameter is an object
[directly visible within a subprogram_body] that represents the actual
parameter passed to the subprogram in a call; it is declared by a
parameter_specification. {expected type (parameter default_expression)
[partial]} For a formal parameter, the expected type for its
default_expression, if any, is that of the formal parameter.
{parameter: See formal parameter}
Legality Rules
18 {parameter mode} The parameter mode of a formal parameter conveys the
direction of information transfer with the actual parameter: in, in out, or
out. Mode in is the default, and is the mode of a parameter defined by an
access_definition. The formal parameters of a function, if any, shall have the
mode in.
18.a Ramification: Access parameters are permitted. This restriction to
in parameters is primarily a methodological restriction, though it
also simplifies implementation for some compiler technologies.
19 A default_expression is only allowed in a parameter_specification for a
formal parameter of mode in.
20/2 {AI95-00348-01} {requires a completion (subprogram_declaration)
[partial]} {requires a completion (generic_subprogram_declaration)
[partial]} A subprogram_declaration or a generic_subprogram_declaration
requires a completion: [a body, a renaming_declaration (see 8.5), or a
pragma Import (see B.1)]. [A completion is not allowed for an
abstract_subprogram_declaration (see 3.9.3) or a null_procedure_declaration
(see 6.7).]
20.a/2 Ramification: {AI95-00348-01} Abstract subprograms and null
procedures are not declared by subprogram_declarations, and so do
not require completion. Protected subprograms are declared by
subprogram_declarations, and so require completion. Note that an
abstract subprogram is a subprogram, and a protected subprogram is
a subprogram, but a generic subprogram is not a subprogram.
21 A name that denotes a formal parameter is not allowed within the
formal_part in which it is declared, nor within the formal_part of a
corresponding body or accept_statement.
21.a Ramification: By contrast, generic_formal_parameter_declarations
are visible to subsequent declarations in the same
generic_formal_part.
Static Semantics
22 {profile} The profile of (a view of) a callable entity is either a
parameter_profile or parameter_and_result_profile[; it embodies information
about the interface to that entity - for example, the profile includes
information about parameters passed to the callable entity. All callable
entities have a profile - enumeration literals, other subprograms, and
entries. An access-to-subprogram type has a designated profile.] Associated
with a profile is a calling convention. A subprogram_declaration declares a
procedure or a function, as indicated by the initial reserved word, with name
and profile as given by its specification.
23/2 {AI95-00231-01} {AI95-00318-02}
{nominal subtype (of a formal parameter) [partial]} The nominal subtype of a
formal parameter is the subtype determined by the optional null_exclusion and
the subtype_mark, or defined by the access_definition, in the
parameter_specification. The nominal subtype of a function result is the
subtype determined by the optional null_exclusion and the subtype_mark, or
defined by the access_definition, in the parameter_and_result_profile.
{nominal subtype (of a function result) [partial]}
24/2 {AI95-00231-01} {AI95-00254-01} {AI95-00318-02} {access parameter} An
access parameter is a formal in parameter specified by an access_definition.
{access result type} An access result type is a function result type specified
by an access_definition. An access parameter or result type is of an anonymous
access type (see 3.10). [Access parameters of an access-to-object type allow
dispatching calls to be controlled by access values. Access parameters of an
access-to-subprogram type permit calls to subprograms passed as parameters
irrespective of their accessibility level.]
24.a/2 Discussion: {AI95-00318-02} Access result types have normal
accessibility and thus don't have any special properties worth
noting here.
25 {subtypes (of a profile)} The subtypes of a profile are:
26 * For any non-access parameters, the nominal subtype of the parameter.
27/2 * {AI95-00254-01} For any access parameters of an access-to-object
type, the designated subtype of the parameter type.
27.1/2 * {AI95-00254-01} For any access parameters of an
access-to-subprogram type, the subtypes of the profile of the
parameter type.
28/2 * {AI95-00231-01} {AI95-00318-02} For any non-access result, the
nominal subtype of the function result.
28.1/2 * {AI95-00318-02} For any access result type of an access-to-object
type, the designated subtype of the result type.
28.2/2 * {AI95-00318-02} For any access result type of an
access-to-subprogram type, the subtypes of the profile of the result
type.
29 [{types (of a profile)} The types of a profile are the types of those
subtypes.]
30/2 {AI95-00348-01} [A subprogram declared by an
abstract_subprogram_declaration is abstract; a subprogram declared by a
subprogram_declaration is not. See 3.9.3, "Abstract Types and Subprograms".
Similarly, a procedure defined by a null_procedure_declaration is a null
procedure; a procedure declared by a subprogram_declaration is not. See 6.7
, "Null Procedures".]
30.1/2 {AI95-00218-03} [An overriding_indicator is used to indicate whether
overriding is intended. See 8.3.1, "Overriding Indicators".]
Dynamic Semantics
31/2 {AI95-00348-01} {elaboration (subprogram_declaration) [partial]} The
elaboration of a subprogram_declaration has no effect.
NOTES
32 1 A parameter_specification with several identifiers is equivalent to
a sequence of single parameter_specifications, as explained in 3.3.
33 2 Abstract subprograms do not have bodies, and cannot be used in a
nondispatching call (see 3.9.3, "Abstract Types and Subprograms").
34 3 The evaluation of default_expressions is caused by certain calls,
as described in 6.4.1. They are not evaluated during the elaboration
of the subprogram declaration.
35 4 Subprograms can be called recursively and can be called
concurrently from multiple tasks.
Examples
36 Examples of subprogram declarations:
37 procedure Traverse_Tree;
procedure Increment(X : in out Integer);
procedure Right_Indent(Margin : out Line_Size); -- see 3.5.4
procedure Switch(From, To : in out Link); -- see 3.10.1
38 function Random return Probability; -- see 3.5.7
39 function Min_Cell(X : Link) return Cell; -- see 3.10.1
function Next_Frame(K : Positive) return Frame; -- see 3.10
function Dot_Product(Left, Right : Vector) return Real; -- see 3.6
40 function "*"(Left, Right : Matrix) return Matrix; -- see 3.6
41 Examples of in parameters with default expressions:
42 procedure Print_Header(Pages : in Natural;
Header : in Line := (1 .. Line'Last => ' '); -- see 3.6
Center : in Boolean := True);
Extensions to Ada 83
42.a {extensions to Ada 83} The syntax for
abstract_subprogram_declaration is added. The syntax for
parameter_specification is revised to allow for access parameters
(see 3.10)
42.b Program units that are library units may have a parent_unit_name
to indicate the parent of a child (see Section 10).
Wording Changes from Ada 83
42.c We have incorporated the rules from RM83-6.5, "Function
Subprograms" here and in 6.3, "Subprogram Bodies"
42.d We have incorporated the definitions of RM83-6.6, "Parameter and
Result Type Profile - Overloading of Subprograms" here.
42.e The syntax rule for defining_operator_symbol is new. It is used
for the defining occurrence of an operator_symbol, analogously to
defining_identifier. Usage occurrences use the direct_name or
selector_name syntactic categories. The syntax rules for
defining_designator and defining_program_unit_name are new.
Extensions to Ada 95
42.f/2 {AI95-00218-03} {extensions to Ada 95} Subprograms now allow
overriding_indicators for better error checking of overriding.
42.g/2 {AI95-00231-01} An optional null_exclusion can be used in a formal
parameter declaration. Similarly, an optional null_exclusion can
be used in a function result.
42.h/2 {AI95-00318-02} The return type of a function can be an anonymous
access type.
Wording Changes from Ada 95
42.i/2 {AI95-00254-01} A description of the purpose of anonymous
access-to-subprogram parameters and the definition of the profile
of subprograms containing them was added.
42.j/2 {AI95-00348-01} Split the production for
subprogram_specification in order to make the declaration of null
procedures (see 6.7) easier.
42.k/2 {AI95-00348-01} Moved the Syntax and Dynamic Semantics for
abstract_subprogram_declaration to 3.9.3, so that the syntax and
semantics are together. This also keeps abstract and null
subprograms similar.
42.l/2 {AI95-00395-01} Revised to allow other_format characters in
operator_symbols in the same way as the underlying constructs.
6.2 Formal Parameter Modes
1 [A parameter_specification declares a formal parameter of mode in, in out,
or out.]
Static Semantics
2 {pass by copy} {by copy parameter passing} {copy parameter passing}
{pass by reference} {by reference parameter passing}
{reference parameter passing} A parameter is passed either by copy or by
reference. [When a parameter is passed by copy, the formal parameter denotes a
separate object from the actual parameter, and any information transfer
between the two occurs only before and after executing the subprogram. When a
parameter is passed by reference, the formal parameter denotes (a view of) the
object denoted by the actual parameter; reads and updates of the formal
parameter directly reference the actual parameter object.]
3 {by-copy type} A type is a by-copy type if it is an elementary type, or if
it is a descendant of a private type whose full type is a by-copy type. A
parameter of a by-copy type is passed by copy.
4 {by-reference type} A type is a by-reference type if it is a descendant of
one of the following:
5 * a tagged type;
6 * a task or protected type;
7 * a nonprivate type with the reserved word limited in its declaration;
7.a Ramification: A limited private type is by-reference only if it
falls under one of the other categories.
8 * a composite type with a subcomponent of a by-reference type;
9 * a private type whose full type is a by-reference type.
10 A parameter of a by-reference type is passed by reference.
{associated object (of a value of a by-reference type)} Each value of a
by-reference type has an associated object. For a parenthesized expression,
qualified_expression, or type_conversion, this object is the one associated
with the operand.
10.a Ramification: By-reference parameter passing makes sense only if
there is an object to reference; hence, we define such an object
for each case.
10.b Since tagged types are by-reference types, this implies that every
value of a tagged type has an associated object. This simplifies
things, because we can define the tag to be a property of the
object, and not of the value of the object, which makes it clearer
that object tags never change.
10.c We considered simplifying things even more by making every value
(and therefore every expression) have an associated object. After
all, there is little semantic difference between a constant object
and a value. However, this would cause problems for untagged
types. In particular, we would have to do a constraint check on
every read of a type conversion (or a renaming thereof) in certain
cases.
10.d/2 {AI95-00318-02} We do not want this definition to depend on the
view of the type; privateness is essentially ignored for this
definition. Otherwise, things would be confusing (does the rule
apply at the call site, at the site of the declaration of the
subprogram, at the site of the return statement?), and requiring
different calls to use different mechanisms would be an
implementation burden.
10.e C.6, "Shared Variable Control" says that a composite type with an
atomic or volatile subcomponent is a by-reference type, among
other things.
10.f {associated object (of a value of a limited type)} Every value of
a limited by-reference type is the value of one and only one
limited object. The associated object of a value of a limited
by-reference type is the object whose value it represents.
{same value (for a limited type)} Two values of a limited
by-reference type are the same if and only if they represent the
value of the same object.
10.g We say "by-reference" above because these statements are not
always true for limited private types whose underlying type is
nonlimited (unfortunately).
11 {unspecified [partial]} For parameters of other types, it is unspecified
whether the parameter is passed by copy or by reference.
11.a Discussion: There is no need to incorporate the discussion of
AI83-00178, which requires pass-by-copy for certain kinds of
actual parameters, while allowing pass-by-reference for others.
This is because we explicitly indicate that a function creates an
anonymous constant object for its result, unless the type is a
return-by-reference type (see 6.5). We also provide a special
dispensation for instances of Unchecked_Conversion to return by
reference, even if the result type is not a return-by-reference
type (see 13.9).
Bounded (Run-Time) Errors
12 {distinct access paths} {access paths (distinct)}
{aliasing: See distinct access paths} {bounded error (cause) [partial]} If one
name denotes a part of a formal parameter, and a second name denotes a part of
a distinct formal parameter or an object that is not part of a formal
parameter, then the two names are considered distinct access paths. If an
object is of a type for which the parameter passing mechanism is not
specified, then it is a bounded error to assign to the object via one access
path, and then read the value of the object via a distinct access path, unless
the first access path denotes a part of a formal parameter that no longer
exists at the point of the second access [(due to leaving the corresponding
callable construct).] {Program_Error (raised by failure of run-time check)}
The possible consequences are that Program_Error is raised, or the newly
assigned value is read, or some old value of the object is read.
12.a Discussion: For example, if we call "P(X => Global_Variable, Y =>
Global_Variable)", then within P, the names "X", "Y", and "
Global_Variable" are all distinct access paths. If
Global_Variable's type is neither pass-by-copy nor
pass-by-reference, then it is a bounded error to assign to
Global_Variable and then read X or Y, since the language does not
specify whether the old or the new value would be read. On the
other hand, if Global_Variable's type is pass-by-copy, then the
old value would always be read, and there is no error. Similarly,
if Global_Variable's type is defined by the language to be
pass-by-reference, then the new value would always be read, and
again there is no error.
12.b Reason: We are saying assign here, not update, because updating
any subcomponent is considered to update the enclosing object.
12.c The "still exists" part is so that a read after the subprogram
returns is OK.
12.d If the parameter is of a by-copy type, then there is no issue here
- the formal is not a view of the actual. If the parameter is of a
by-reference type, then the programmer may depend on updates
through one access path being visible through some other access
path, just as if the parameter were of an access type.
12.e Implementation Note: The implementation can keep a copy in a
register of a parameter whose parameter-passing mechanism is not
specified. If a different access path is used to update the object
(creating a bounded error situation), then the implementation can
still use the value of the register, even though the in-memory
version of the object has been changed. However, to keep the error
properly bounded, if the implementation chooses to read the
in-memory version, it has to be consistent -- it cannot then
assume that something it has proven about the register is true of
the memory location. For example, suppose the formal parameter is
L, the value of L(6) is now in a register, and L(6) is used in an
indexed_component as in "A(L(6)) := 99;", where A has bounds 1..3.
If the implementation can prove that the value for L(6) in the
register is in the range 1..3, then it need not perform the
constraint check if it uses the register value. However, if the
memory value of L(6) has been changed to 4, and the implementation
uses that memory value, then it had better not alter memory
outside of A.
12.f Note that the rule allows the implementation to pass a parameter
by reference and then keep just part of it in a register, or,
equivalently, to pass part of the parameter by reference and
another part by copy.
12.g Reason: We do not want to go so far as to say that the mere
presence of aliasing is wrong. We wish to be able to write the
following sorts of things in standard Ada:
12.h procedure Move ( Source : in String;
Target : out String;
Drop : in Truncation := Error;
Justify : in Alignment := Left;
Pad : in Character := Space);
-- Copies elements from Source to Target (safely if they overlap)
12.i This is from the standard string handling package. It would be
embarrassing if this couldn't be written in Ada!
12.j The "then" before "read" in the rule implies that the
implementation can move a read to an earlier place in the code,
but not to a later place after a potentially aliased assignment.
Thus, if the subprogram reads one of its parameters into a local
variable, and then updates another potentially aliased one, the
local copy is safe - it is known to have the old value. For
example, the above-mentioned Move subprogram can be implemented by
copying Source into a local variable before assigning into Target.
12.k For an assignment_statement assigning one array parameter to
another, the implementation has to check which direction to copy
at run time, in general, in case the actual parameters are
overlapping slices. For example:
12.l procedure Copy(X : in out String; Y: String) is
begin
X := Y;
end Copy;
12.m It would be wrong for the compiler to assume that X and Y do not
overlap (unless, of course, it can prove otherwise).
NOTES
13 5 A formal parameter of mode in is a constant view (see 3.3); it
cannot be updated within the subprogram_body.
Extensions to Ada 83
13.a {extensions to Ada 83} The value of an out parameter may be read.
An out parameter is treated like a declared variable without an
explicit initial expression.
Wording Changes from Ada 83
13.b Discussion of copy-in for parts of out parameters is now covered
in 6.4.1, "Parameter Associations".
13.c The concept of a by-reference type is new to Ada 95.
13.d We now cover in a general way in 3.7.2 the rule regarding
erroneous execution when a discriminant is changed and one of the
parameters depends on the discriminant.
6.3 Subprogram Bodies
1 [A subprogram_body specifies the execution of a subprogram.]
Syntax
2/2 {AI95-00218-03} subprogram_body ::=
[overriding_indicator]
subprogram_specification is
declarative_part
begin
handled_sequence_of_statements
end [designator];
3 If a designator appears at the end of a subprogram_body, it shall
repeat the defining_designator of the subprogram_specification.
Legality Rules
4 [In contrast to other bodies,] a subprogram_body need not be the
completion of a previous declaration[, in which case the body declares the
subprogram]. If the body is a completion, it shall be the completion of a
subprogram_declaration or generic_subprogram_declaration. The profile of a
subprogram_body that completes a declaration shall conform fully to that of
the declaration. {full conformance (required)}
Static Semantics
5 A subprogram_body is considered a declaration. It can either complete a
previous declaration, or itself be the initial declaration of the subprogram.
Dynamic Semantics
6 {elaboration (non-generic subprogram_body) [partial]} The elaboration of a
non-generic subprogram_body has no other effect than to establish that the
subprogram can from then on be called without failing the Elaboration_Check.
6.a Ramification: See 12.2 for elaboration of a generic body. Note
that protected subprogram_bodies never get elaborated; the
elaboration of the containing protected_body allows them to be
called without failing the Elaboration_Check.
7 {execution (subprogram_body) [partial]} [The execution of a
subprogram_body is invoked by a subprogram call.] For this execution the
declarative_part is elaborated, and the handled_sequence_of_statements is then
executed.
Examples
8 Example of procedure body:
9 procedure Push(E : in Element_Type; S : in out Stack) is
begin
if S.Index = S.Size then
raise Stack_Overflow;
else
S.Index := S.Index + 1;
S.Space(S.Index) := E;
end if;
end Push;
10 Example of a function body:
11 function Dot_Product(Left, Right : Vector) return Real is
Sum : Real := 0.0;
begin
Check(Left'First = Right'First and Left'Last = Right'Last);
for J in Left'Range loop
Sum := Sum + Left(J)*Right(J);
end loop;
return Sum;
end Dot_Product;
Extensions to Ada 83
11.a {extensions to Ada 83} A renaming_declaration may be used instead
of a subprogram_body.
Wording Changes from Ada 83
11.b The syntax rule for subprogram_body now uses the syntactic
category handled_sequence_of_statements.
11.c The declarative_part of a subprogram_body is now required; that
doesn't make any real difference, because a declarative_part can
be empty.
11.d We have incorporated some rules from RM83-6.5 here.
11.e RM83 forgot to restrict the definition of elaboration of a
subprogram_body to non-generics.
Wording Changes from Ada 95
11.f/2 {AI95-00218-03} Overriding_indicator is added to subprogram_body.
6.3.1 Conformance Rules
1 {conformance} [When 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.]
Static Semantics
2/1 {8652/0011} {AI95-00117-01} {convention} {calling convention} [As
explained in B.1, "Interfacing Pragmas", a convention can be specified for an
entity.] Unless this International Standard 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:
3 * {Ada calling convention} {calling convention (Ada)} The default
calling convention for any subprogram not listed below is Ada. [A
pragma Convention, Import, or Export may be used to override the
default calling convention (see B.1)].
3.a Ramification: See also the rule about renamings-as-body in 8.5.4.
4 * {Intrinsic calling convention} {calling convention (Intrinsic)} The
Intrinsic calling convention represents subprograms that are "built
in" to the compiler. The default calling convention is Intrinsic for the
following:
5 * an enumeration literal;
6 * a "/=" operator declared implicitly due to the declaration of "="
(see 6.6);
7 * any other implicitly declared subprogram unless it is a
dispatching operation of a tagged type;
8 * an inherited subprogram of a generic formal tagged type with
unknown discriminants;
8.a.1/1 Reason: Consider:
8.a.2/1 package P is
type Root is tagged null record;
procedure Proc(X: Root);
end P;
8.a.3/1 generic
type Formal(<>) is new Root with private;
package G is
...
end G;
8.a.4/1 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.
end G;
8.a.5/1 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.
8.a.6/1 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 'Access.
9 * an attribute that is a subprogram;
10/2 * {AI95-00252-01} a subprogram declared immediately within a
protected_body;
10.1/2 * {AI95-00252-01} {AI95-00407-01} any prefixed view of a subprogram
(see 4.1.3).
10.a/2 Reason: The profile of a prefixed view is different 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.
11 [The Access attribute is not allowed for Intrinsic subprograms.]
11.a 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 intrinsic.
11.b Whenever we wish to disallow the Access attribute in order to ease
implementation, we make the subprogram Intrinsic. Several
language-defined subprograms have "pragma Convention(Intrinsic,
...);". An implementation might actually implement this as "
pragma Import(Intrinsic, ...);", if there is really no body, and
the implementation of the subprogram is built into the code
generator.
11.c 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 unit.
11.d The "implicitly declared subprogram" above refers to predefined
operators (other than the "=" of a tagged type) and the inherited
subprograms of untagged types.
12 * {protected calling convention} {calling convention (protected)} The
default calling convention is protected for a protected subprogram,
and for an access-to-subprogram type with the reserved word protected
in its definition.
13 * {entry calling convention} {calling convention (entry)} The default
calling convention is entry for an entry.
13.1/2 * {AI95-00254-01} {AI95-00409-01} The calling convention for an
anonymous access-to-subprogram parameter or anonymous
access-to-subprogram result is protected if the reserved word
protected appears in its definition and otherwise is the convention of
the subprogram that contains the parameter.
13.a/2 Ramification: The calling convention for other anonymous
access-to-subprogram types is Ada.
13.2/1 * {8652/0011} {AI95-00117-01} [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.
13.a.1/1 Reason: 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.
14 Of these four conventions, only Ada and Intrinsic are allowed as a
convention_identifier in a pragma Convention, Import, or Export.
14.a Discussion: The names of the protected and entry calling
conventions cannot be used in the interfacing pragmas. Note that
protected and entry are reserved words.
15/2 {AI95-00409-01} {type conformance} {profile (type conformant)} 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. {type profile: See profile, type conformant}
15.a/2 Discussion: {AI95-00409-01} 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.
15.b/2 {AI95-00409-01} Similarly, for anonymous access-to-subprogram
parameters, the designated profiles of the types, not the types
themselves, have to be conformant.
16/2 {AI95-00318-02} {AI95-00409-01} {mode conformance}
{profile (mode conformant)} Two profiles are mode conformant if they are
type-conformant, and corresponding parameters have identical modes, and, for
access parameters or access result types, the designated subtypes statically
match, or the designated profiles are subtype conformant.
{statically matching (required) [partial]}
17 {subtype conformance} {profile (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 profile. {statically matching (required) [partial]}
17.a Ramification: {generic contract issue [partial]}
18 {full conformance (for profiles)} {profile (fully conformant)} Two
profiles are fully conformant if they are subtype-conformant, and
corresponding parameters have the same names and have default_expressions that
are fully conformant with one another.
18.a 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.
19 {full conformance (for expressions)} Two expressions are fully conformant
if, [after replacing each use of an operator with the equivalent
function_call:]
20 * 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 character_literal) or to a different
expanded name in the other; and
21 * each direct_name, character_literal, and selector_name that is not
part of the prefix of an expanded name in one denotes the same
declaration as the corresponding direct_name, character_literal, or
selector_name in the other; and
21.a Ramification: Note that it doesn't say "respectively" because a
direct_name can correspond to a selector_name, and vice-versa, 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
a direct_name or selector_name to be replaced with one denoting a
distinct renaming (except for direct_names and selector_names in
prefixes of expanded names). Note that calls using operator
notation are equivalent to calls using prefix notation.
21.b Given the following declarations:
21.c package A is
function F(X : Integer := 1) return Boolean;
end A;
21.d with A;
package B is
package A_View renames A;
function F_View(X : Integer := 9999) return Boolean renames F;
end B;
21.e with A, B; use A, B;
procedure Main is ...
21.f 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_expressions.
21.1/1 * {8652/0018} {AI95-00175-01} each attribute_designator in one must
be the same as the corresponding attribute_designator in the other; and
22 * each primary that is a literal in one has the same value as the
corresponding literal in the other.
22.a Ramification: The literals may be written differently.
22.b Ramification: Note that the above definition makes full
conformance a transitive relation.
23 {full conformance (for known_discriminant_parts)} Two
known_discriminant_parts 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_expressions that are fully
conformant with one another. {statically matching (required) [partial]}
24 {full conformance (for discrete_subtype_definitions)} Two
discrete_subtype_definitions are fully conformant if they are both
subtype_indications or are both ranges, the subtype_marks (if any) denote the
same subtype, and the corresponding simple_expressions of the ranges (if any)
fully conform.
24.a Ramification: In the subtype_indication case, any ranges have to
be corresponding; that is, two subtype_indications cannot conform
unless both or neither has a range.
24.b Discussion: This definition is used in 9.5.2, "
Entries and Accept Statements" for the conformance required
between the discrete_subtype_definitions of an entry_declaration
for a family of entries and the corresponding
entry_index_specification of the entry_body.
24.1/2 {AI95-00345-01} {AI95-00397-01} {prefixed view profile} 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.
24.c/2 Discussion: This definition is used to define how primitive
subprograms of interfaces match operations in task and protected
type definitions (see 9.1 and 9.4).
24.d/2 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
operations.
Implementation Permissions
25 An implementation may declare an operator declared in a language-defined
library unit to be intrinsic.
Extensions to Ada 83
25.a {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 T)".
Wording Changes from Ada 95
25.b/2 {8652/0011} {AI95-00117-01} Corrigendum: 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.
25.c/2 {8652/0018} {AI95-00175-01} Corrigendum: Added wording to ensure
that two attributes conform only if they have the same
attribute_designator.
25.d/2 {AI95-00252-01} {AI95-00254-01} {AI95-00407-01} Defined the
calling convention for anonymous access-to-subprogram types and
for prefixed views of subprograms (see 4.1.3).
25.e/2 {AI95-00318-02} Defined the conformance of access result types
(see 6.1).
25.f/2 {AI95-00345-01} {AI95-00397-01} Defined the prefixed view profile
of subprograms for later use.
25.g/2 {AI95-00409-01} Defined the conformance of anonymous
access-to-subprogram parameters.
6.3.2 Inline Expansion of Subprograms
1 [Subprograms may be expanded in line at the call site.]
Syntax
2 {program unit pragma (Inline) [partial]}
{pragma, program unit (Inline) [partial]} The form of a pragma Inline,
which is a program unit pragma (see 10.1.5), is as follows:
3 pragma Inline(name {, name});
Legality Rules
4 The pragma shall apply to one or more callable entities or generic
subprograms.
Static Semantics
5 If a pragma Inline applies to a callable entity, this indicates that
inline expansion is desired for all calls to that entity. If a pragma Inline
applies to a generic subprogram, this indicates that inline expansion is
desired for all calls to all instances of that generic subprogram.
5.a Ramification: Note that inline expansion is desired no matter what
name is used in the call. This allows one to request inlining for
only one of several overloaded subprograms as follows:
5.b package IO is
procedure Put(X : in Integer);
procedure Put(X : in String);
procedure Put(X : in Character);
private
procedure Character_Put(X : in Character) renames Put;
pragma Inline(Character_Put);
end IO;
5.c with IO; use IO;
procedure Main is
I : Integer;
C : Character;
begin
...
Put(C); -- Inline expansion is desired.
Put(I); -- Inline expansion is NOT desired.
end Main;
5.d Ramification: The meaning of a subprogram can be changed by a
pragma Inline only in the presence of failing checks (see 11.6).
Implementation Permissions
6 For each call, an implementation is free to follow or to ignore the
recommendation expressed by the pragma.
6.a Ramification: Note, in particular, that the recommendation cannot
always be followed for a recursive call, and is often infeasible
for entries. Note also that the implementation can inline calls
even when no such desire was expressed by a pragma, so long as the
semantics of the program remains unchanged.
6.1/2 {AI95-00309-01} An implementation may allow a pragma Inline that has an
argument which is a direct_name denoting a subprogram_body of the same
declarative_part.
6.b/2 Reason: This is allowed for Ada 83 compatibility. This is only a
permission as this usage is considered obsolescent.
6.c/2 Discussion: We only need to allow this in declarative_parts,
because a body is only allowed in another body, and these all have
declarative_parts.
NOTES
7 6 The name in a pragma Inline can denote more than one entity in the
case of overloading. Such a pragma applies to all of the denoted
entities.
Incompatibilities With Ada 83
7.a/2 {AI95-00309-01} {incompatibilities with Ada 83} A pragma Inline
cannot refer to a subprogram_body outside of that body. The pragma
can be given inside of the subprogram body. Ada 2005 adds an
Implementation Permission to allow this usage for compatibility
(and Ada 95 implementations also can use this permission), but
implementations do not have to allow such pragmas.
Extensions to Ada 83
7.b {extensions to Ada 83} A pragma Inline is allowed inside a
subprogram_body if there is no corresponding
subprogram_declaration. This is for uniformity with other program
unit pragmas.
Extensions to Ada 95
7.c/2 {AI95-00309-01} {extensions to Ada 95} Amendment Correction:
Implementations are allowed to let Pragma Inline apply to a
subprogram_body.
6.4 Subprogram Calls
1 {subprogram call} A subprogram call is either a procedure_call_statement
or a function_call; [it invokes the execution of the subprogram_body. The call
specifies the association of the actual parameters, if any, with formal
parameters of the subprogram.]
Syntax
2 procedure_call_statement ::=
procedure_name;
| procedure_prefix actual_parameter_part;
3 function_call ::=
function_name
| function_prefix actual_parameter_part
4 actual_parameter_part ::=
(parameter_association {, parameter_association})
5 parameter_association ::=
[formal_parameter_selector_name =>] explicit_actual_parameter
6 explicit_actual_parameter ::= expression | variable_name
7 {named association} {positional association} A parameter_association
is named or positional according to whether or not the
formal_parameter_selector_name is specified. Any positional
associations shall precede any named associations. Named associations
are not allowed if the prefix in a subprogram call is an attribute_-
reference.
7.a Ramification: This means that the formal parameter names used in
describing predefined attributes are to aid presentation of their
semantics, but are not intended for use in actual calls.
Name Resolution Rules
8/2 {AI95-00310-01} The name or prefix given in a procedure_call_statement
shall resolve to denote a callable entity that is a procedure, or an entry
renamed as (viewed as) a procedure. The name or prefix given in a
function_call shall resolve to denote a callable entity that is a function.
The name or prefix shall not resolve to denote an abstract subprogram unless
it is also a dispatching subprogram. [When there is an actual_parameter_-
part, the prefix can be an implicit_dereference of an access-to-subprogram
value.]
8.a.1/2 Discussion: {AI95-00310-01} This rule is talking about dispatching
operations (which is a static concept) and not about dispatching
calls (which is a dynamic concept).
8.a Ramification: The function can be an operator, enumeration
literal, attribute that is a function, etc.
9 A subprogram call shall contain at most one association for each formal
parameter. Each formal parameter without an association shall have a
default_expression (in the profile of the view denoted by the name or prefix
). This rule is an overloading rule (see 8.6).
Dynamic Semantics
10/2 {AI95-00345-01} {execution (subprogram call) [partial]} For the execution
of a subprogram call, the name or prefix of the call is evaluated, and each
parameter_association is evaluated (see 6.4.1). If a default_expression is
used, an implicit parameter_association is assumed for this rule. These
evaluations are done in an arbitrary order. The subprogram_body is then
executed, or a call on an entry or protected subprogram is performed (see
3.9.2). Finally, if the subprogram completes normally, then after it is left,
any necessary assigning back of formal to actual parameters occurs (see
6.4.1).
10.a Discussion: The implicit association for a default is only for
this run-time rule. At compile time, the visibility rules are
applied to the default at the place where it occurs, not at the
place of a call.
10.b To be honest: If the subprogram is inherited, see 3.4, "
Derived Types and Classes".
10.c If the subprogram is protected, see 9.5.1, "
Protected Subprograms and Protected Actions".
10.d If the subprogram is really a renaming of an entry, see 9.5.3,
"Entry Calls".
10.d.1/2 {AI95-00345-01} If the subprogram is implemented by an entry or
protected subprogram, it will be treated as a dispatching call to
the corresponding entry (see 9.5.3, "Entry Calls") or protected
subprogram (see 9.5.1, "
Protected Subprograms and Protected Actions").
10.e/2 {AI95-00348-01} Normally, the subprogram_body that is executed by
the above rule is the one for the subprogram being called. For an
enumeration literal, implicitly declared (but noninherited)
subprogram, null procedure, or an attribute that is a subprogram,
an implicit body is assumed. For a dispatching call, 3.9.2, "
Dispatching Operations of Tagged Types" defines which
subprogram_body is executed.
10.1/2 {AI95-00407-01} If the name or prefix of a subprogram call denotes a
prefixed view (see 4.1.3), the subprogram call is equivalent to a call on the
underlying subprogram, with the first actual parameter being provided by the
prefix of the prefixed view (or the Access attribute of this prefix if the
first formal parameter is an access parameter), and the remaining actual
parameters given by the actual_parameter_part, if any.
11/2 {AI95-00318-02} {Program_Error (raised by failure of run-time check)} The
exception Program_Error is raised at the point of a function_call if the
function completes normally without executing a return statement.
11.a Discussion: We are committing to raising the exception at the
point of call, for uniformity - see AI83-00152. This happens after
the function is left, of course.
11.b Note that there is no name for suppressing this check, since the
check imposes no time overhead and minimal space overhead (since
it can usually be statically eliminated as dead code).
12/2 {AI95-00231-01} A function_call denotes a constant, as defined in 6.5;
the nominal subtype of the constant is given by the nominal subtype of the
function result. {nominal subtype (of the result of a function_call)
[partial]} {constant (result of a function_call) [partial]}
Examples
13 Examples of procedure calls:
14 Traverse_Tree; -- see 6.1
Print_Header(128, Title, True); -- see 6.1
15 Switch(From => X, To => Next); -- see 6.1
Print_Header(128, Header => Title, Center => True); -- see 6.1
Print_Header(Header => Title, Center => True, Pages => 128); -- see 6.1
16 Examples of function calls:
17 Dot_Product(U, V) -- see 6.1 and 6.3
Clock -- see 9.6
F.all -- presuming F is of an access-to-subprogram type - see 3.10
18 Examples of procedures with default expressions:
19 procedure Activate(Process : in Process_Name;
After : in Process_Name := No_Process;
Wait : in Duration := 0.0;
Prior : in Boolean := False);
20 procedure Pair(Left, Right : in Person_Name := new Person); -- see 3.10.1
21 Examples of their calls:
22 Activate(X);
Activate(X, After => Y);
Activate(X, Wait => 60.0, Prior => True);
Activate(X, Y, 10.0, False);
23 Pair;
Pair(Left => new Person, Right => new Person);
NOTES
24 7 If a default_expression is used for two or more parameters in a
multiple parameter_specification, the default_expression is evaluated
once for each omitted parameter. Hence in the above examples, the two
calls of Pair are equivalent.
Examples
25 Examples of overloaded subprograms:
26 procedure Put(X : in Integer);
procedure Put(X : in String);
27 procedure Set(Tint : in Color);
procedure Set(Signal : in Light);
28 Examples of their calls:
29 Put(28);
Put("no possible ambiguity here");
30 Set(Tint => Red);
Set(Signal => Red);
Set(Color'(Red));
31 -- Set(Red) would be ambiguous since Red may
-- denote a value either of type Color or of type Light
Wording Changes from Ada 83
31.a We have gotten rid of parameters "of the form of a type
conversion" (see RM83-6.4.1(3)). The new view semantics of type_conversions
allows us to use normal type_conversions instead.
31.b We have moved wording about run-time semantics of parameter
associations to 6.4.1.
31.c We have moved wording about raising Program_Error for a function
that falls off the end to here from RM83-6.5.
Extensions to Ada 95
31.d/2 {AI95-00310-01} {extensions to Ada 95} Nondispatching abstract
operations are no longer considered when resolving a subprogram
call. That makes it possible to use abstract to "undefine" a
predefined operation for an untagged type. That's especially
helpful when defining custom arithmetic packages.
Wording Changes from Ada 95
31.e/2 {AI95-00231-01} Changed the definition of the nominal subtype of a
function_call to use the nominal subtype wording of 6.1, to take
into account null_exclusions and access result types.
31.f/2 {AI95-00345-01} Added wording to clarify that the meaning of a
call on a subprogram "implemented by" an entry or protected
operation is defined by 3.9.2.
31.g/2 {AI95-00407-01} Defined the meaning of a call on a prefixed view
of a subprogram (see 4.1.3).
6.4.1 Parameter Associations
1 [{parameter passing} A parameter association defines the association
between an actual parameter and a formal parameter.]
Language Design Principles
1.a The parameter passing rules for out parameters are designed to
ensure that the parts of a type that have implicit initial values
(see 3.3.1) don't become "de-initialized" by being passed as an
out parameter.
Name Resolution Rules
2 The formal_parameter_selector_name of a parameter_association shall
resolve to denote a parameter_specification of the view being called.
3 {actual parameter (for a formal parameter)} The actual parameter is either
the explicit_actual_parameter given in a parameter_association for a given
formal parameter, or the corresponding default_expression if no
parameter_association is given for the formal parameter.
{expected type (actual parameter)} The expected type for an actual parameter is
the type of the corresponding formal parameter.
3.a To be honest: The corresponding default_expression is the one of
the corresponding formal parameter in the profile of the view
denoted by the name or prefix of the call.
4 If the mode is in, the actual is interpreted as an expression; otherwise,
the actual is interpreted only as a name, if possible.
4.a Ramification: This formally resolves the ambiguity present in the
syntax rule for explicit_actual_parameter. Note that we don't
actually require that the actual be a name if the mode is not in;
we do that below.
Legality Rules
5 If the mode is in out or out, the actual shall be a name that denotes a
variable.
5.a Discussion: We no longer need "or a type_conversion whose argument
is the name of a variable," because a type_conversion is now a
name, and a type_conversion of a variable is a variable.
5.b Reason: The requirement that the actual be a (variable) name is
not an overload resolution rule, since we don't want the
difference between expression and name to be used to resolve
overloading. For example:
5.c procedure Print(X : in Integer; Y : in Boolean := True);
procedure Print(Z : in out Integer);
. . .
Print(3); -- Ambiguous!
5.d The above call to Print is ambiguous even though the call is not
compatible with the second Print which requires an actual that is
a (variable) name ("3" is an expression, not a name). This
requirement is a legality rule, so overload resolution fails
before it is considered, meaning that the call is ambiguous.
6 The type of the actual parameter associated with an access parameter shall
be convertible (see 4.6) to its anonymous access type.
{convertible (required) [partial]}
Dynamic Semantics
7 {evaluation (parameter_association) [partial]} For the evaluation of a
parameter_association:
8 * The actual parameter is first evaluated.
9 * For an access parameter, the access_definition is elaborated, which
creates the anonymous access type.
10 * For a parameter [(of any mode)] that is passed by reference (see 6.2
), a view conversion of the actual parameter to the nominal subtype of
the formal parameter is evaluated, and the formal parameter denotes
that conversion. {implicit subtype conversion (parameter passing)
[partial]}
10.a Discussion: We are always allowing sliding, even for [in[ out
by-reference parameters.
11 * {assignment operation (during evaluation of a parameter_association)}
For an in or in out parameter that is passed by copy (see 6.2), the
formal parameter object is created, and the value of the actual
parameter is converted to the nominal subtype of the formal parameter
and assigned to the formal.
{implicit subtype conversion (parameter passing) [partial]}
11.a Ramification: The conversion mentioned here is a value conversion.
12 * For an out parameter that is passed by copy, the formal parameter
object is created, and:
13 * For an access type, the formal parameter is initialized from the
value of the actual, without a constraint check;
13.a Reason: This preserves the Language Design Principle that an
object of an access type is always initialized with a "
reasonable" value.
14 * For a composite type with discriminants or that has implicit
initial values for any subcomponents (see 3.3.1), the behavior is
as for an in out parameter passed by copy.
14.a Reason: This ensures that no part of an object of such a type can
become "de-initialized" by being part of an out parameter.
14.b Ramification: This includes an array type whose component type is
an access type, and a record type with a component that has a
default_expression, among other things.
15 * For any other type, the formal parameter is uninitialized. If
composite, a view conversion of the actual parameter to the
nominal subtype of the formal is evaluated [(which might raise
Constraint_Error)], and the actual subtype of the formal is that
of the view conversion. If elementary, the actual subtype of the
formal is given by its nominal subtype.
15.a Ramification: This case covers scalar types, and composite types
whose subcomponent's subtypes do not have any implicit initial
values. The view conversion for composite types ensures that if
the lengths don't match between an actual and a formal array
parameter, the Constraint_Error is raised before the call, rather
than after.
16 {constrained (object) [partial]} {unconstrained (object) [partial]} A
formal parameter of mode in out or out with discriminants is constrained if
either its nominal subtype or the actual parameter is constrained.
17 {parameter copy back} {copy back of parameters}
{parameter assigning back} {assigning back of parameters}
{assignment operation (during parameter copy back)} After normal completion and
leaving of a subprogram, for each in out or out parameter that is passed by
copy, the value of the formal parameter is converted to the subtype of the
variable given as the actual parameter and assigned to it.
{implicit subtype conversion (parameter passing) [partial]} These conversions
and assignments occur in an arbitrary order.
17.a Ramification: The conversions mentioned above during parameter
passing might raise Constraint_Error - (see 4.6).
17.b Ramification: If any conversion or assignment as part of parameter
passing propagates an exception, the exception is raised at the
place of the subprogram call; that is, it cannot be handled inside
the subprogram_body.
17.c Proof: Since these checks happen before or after executing the
subprogram_body, the execution of the subprogram_body does not
dynamically enclose them, so it can't handle the exceptions.
17.d Discussion: The variable we're talking about is the one denoted by
the variable_name given as the explicit_actual_parameter. If this
variable_name is a type_conversion, then the rules in 4.6 for
assigning to a view conversion apply. That is, if X is of subtype
S1, and the actual is S2(X), the above-mentioned conversion will
convert to S2, and the one mentioned in 4.6 will convert to S1.
Extensions to Ada 83
17.e {extensions to Ada 83} In Ada 95, a program can rely on the fact
that passing an object as an out parameter does not "
de-initialize" any parts of the object whose subtypes have implicit initial
values. (This generalizes the RM83 rule that required copy-in for
parts that were discriminants or of an access type.)
Wording Changes from Ada 83
17.f We have eliminated the subclause on Default Parameters, as it is
subsumed by earlier clauses and subclauses.
6.5 Return Statements
1/2 {AI95-00318-02} A simple_return_statement or extended_return_statement
(collectively called a return statement) {return statement} is used to
complete the execution of the innermost enclosing subprogram_body, entry_-
body, or accept_statement.
Syntax
2/2 {AI95-00318-02} simple_return_statement ::= return [expression];
2.1/2 {AI95-00318-02} extended_return_statement ::=
return defining_identifier
: [aliased] return_subtype_indication [:= expression] [do
handled_sequence_of_statements
end return];
2.2/2 {AI95-00318-02} return_subtype_indication ::= subtype_indication
| access_definition
Name Resolution Rules
3/2 {AI95-00318-02} {result subtype (of a function)} The result subtype of a
function is the subtype denoted by the subtype_mark, or defined by the
access_definition, after the reserved word return in the profile of the
function.{expected type (expression of simple_return_statement) [partial]} The
expected type for the expression, if any, of a simple_return_statement is the
result type of the corresponding function.
{expected type (expression of extended_return_statement) [partial]} The
expected type for the expression of an extended_return_statement is that of
the return_subtype_indication.
3.a To be honest: The same applies to generic functions.
Legality Rules
4/2 {AI95-00318-02} {apply (to a callable construct by a return statement)} A
return statement shall be within a callable construct, and it applies to the
innermost callable construct or extended_return_statement that contains it. A
return statement shall not be within a body that is within the construct to
which the return statement applies.
5/2 {AI95-00318-02} A function body shall contain at least one return
statement that applies to the function body, unless the function contains
code_statements. A simple_return_statement shall include an expression if and
only if it applies to a function body. An extended_return_statement shall
apply to a function body.
5.a/2 Reason: {AI95-00318-02} The requirement that a function body has
to have at least one return statement is a "helpful" restriction.
There has been some interest in lifting this restriction, or
allowing a raise statement to substitute for the return statement.
However, there was enough interest in leaving it as is that we
decided not to change it.
5.b/2 Ramification: {AI95-00318-02} A return statement can apply to an
extended_return_statement, so a simple_return_statement without an
expression can be given in one. However, neither simple_return_-
statement with an expression nor an extended_return_statement can
be given inside an extended_return_statement, as they must apply
(directly) to a function body.
5.1/2 {AI95-00318-02} For an extended_return_statement that applies to a
function body:
5.2/2 * {AI95-00318-02} If the result subtype of the function is defined by
a subtype_mark, the return_subtype_indication shall be a
subtype_indication. The type of the subtype_indication shall be the
result type of the function. If the result subtype of the function is
constrained, then the subtype defined by the subtype_indication shall
also be constrained and shall statically match this result subtype.
{statically matching (required) [partial]} If the result subtype of the
function is unconstrained, then the subtype defined by the
subtype_indication shall be a definite subtype, or there shall be an
expression.
5.3/2 * {AI95-00318-02} If the result subtype of the function is defined by
an access_definition, the return_subtype_indication shall be an
access_definition. The subtype defined by the access_definition shall
statically match the result subtype of the function. The accessibility
level of this anonymous access subtype is that of the result subtype.
5.4/2 {AI95-00318-02} For any return statement that applies to a function body:
5.5/2 * {AI95-00318-02} If the result subtype of the function is limited,
then the expression of the return statement (if any) shall be an
aggregate, a function call (or equivalent use of an operator), or a
qualified_expression or parenthesized expression whose operand is one
of these.
5.c/2 Discussion: In other words, if limited, the expression must
produce a "new" object, rather than being the name of a
preexisting object (which would imply copying).
5.6/2 * {AI95-00416-01} If the result subtype of the function is class-wide,
the accessibility level of the type of the expression of the return
statement shall not be statically deeper than that of the master that
elaborated the function body. If the result subtype has one or more
unconstrained access discriminants, the accessibility level of the
anonymous access type of each access discriminant, as determined by
the expression of the simple_return_statement or the return_subtype_-
indication, shall not be statically deeper than that of the master
that elaborated the function body.
5.d/2 Discussion: We know that if the result type is class wide, then
there must be an expression of the return statement. Similarly, if
the result subtype is unconstrained, then either the return_-
subtype_indication (if any) is constrained, or there must be an
expression.
Static Semantics
5.7/2 {AI95-00318-02} {return object (extended_return_statement) [partial]}
Within an extended_return_statement, the return object is declared with the
given defining_identifier, with the nominal subtype defined by the return_-
subtype_indication.
Dynamic Semantics
5.8/2 {AI95-00318-02} {AI95-00416-01} {execution (extended_return_statement)
[partial]} For the execution of an extended_return_statement, the
subtype_indication or access_definition is elaborated. This creates the
nominal subtype of the return object. If there is an expression, it is
evaluated and converted to the nominal subtype (which might raise
Constraint_Error - see 4.6{implicit subtype conversion (function return)
[partial]} ); the return object is created and the converted value is
assigned to the return object. Otherwise, the return object is created and
initialized by default as for a stand-alone object of its nominal subtype (see
3.3.1). If the nominal subtype is indefinite, the return object is constrained
by its initial value.{creation (of a return object) [partial]}
5.e/2 Ramification: If the result type is controlled or has a controlled
part, appropriate calls on Initialize or Adjust are performed
prior to executing the handled_sequence_of_statements, except when
the initial expression is an aggregate (which requires
build-in-place with no call on Adjust).
5.f/2 If the return statement is left without resulting in a return (for
example, due to an exception propagated from the expression or the
handled_sequence_of_statements, or a goto out of the
handled_sequence_of_statements), the return object is finalized
prior to leaving the return statement.
6/2 {AI95-00318-02} {execution (simple_return_statement) [partial]} For the
execution of a simple_return_statement, the expression (if any) is first
evaluated, converted to the result subtype, and then is assigned to the
anonymous return object. {return object (simple_return_statement) [partial]}
{implicit subtype conversion (function return) [partial]}
6.a Ramification: The conversion might raise Constraint_Error - (see
4.6).
7/2 {AI95-00318-02} {AI95-00416-01} [If the return object has any parts that
are tasks, the activation of those tasks does not occur until after the
function returns (see 9.2).]
7.a/2 Proof: This is specified by the rules in 9.2.
7.b/2 Reason: Only the caller can know when task activations should take
place, as it depends on the context of the call. If the function
is being used to initialize the component of some larger object,
then that entire object must be initialized before any task
activations. Even after the outer object is fully initialized,
task activations are still postponed until the begin at the end of
the declarative part if the function is being used to initialize
part of a declared object.
8/2 {AI95-00318-02} {AI95-00344-01} If the result type of a function is a
specific tagged type, the tag of the return object is that of the result type.
If the result type is class-wide, the tag of the return object is that of the
value of the expression. A check is made that the accessibility level of the
type identified by the tag of the result is not deeper than that of the master
that elaborated the function body. If this check fails, Program_Error is
raised.{Program_Error (raised by failure of run-time check)}
{Accessibility_Check [partial]}
{check, language-defined (Accessibility_Check)}
8.a/2 Ramification: {AI95-00318-02} The first sentence is true even if
the tag of the expression is different, which could happen if the
expression were a view conversion or a dereference of an access
value. Note that for a limited type, because of the restriction to
aggregates and function calls (and no conversions), the tag will
already match.
8.b/2 Reason: {AI95-00318-02} The first rule ensures that a function
whose result type is a specific tagged type always returns an
object whose tag is that of the result type. This is important for
dispatching on controlling result, and allows the caller to
allocate the appropriate amount of space to hold the value being
returned (assuming there are no discriminants).
8.c/2 The check prevents the returned object from outliving its type.
Note that this check cannot fail for a specific tagged type, as
the tag represents the function's type, which necessarily must be
declared outside of the function.
Paragraphs 9 through 20 were deleted.
21/2 {AI95-00318-02} {AI95-00402-01} {AI95-00416-01} If the result subtype of
a function has one or more unconstrained access discriminants, a check is made
that the accessibility level of the anonymous access type of each access
discriminant, as determined by the expression or the return_subtype_indication
of the function, is not deeper than that of the master that elaborated the
function body. If this check fails, Program_Error is raised.
{Program_Error (raised by failure of run-time check)} {Accessibility_Check
[partial]} {check, language-defined (Accessibility_Check)}
21.a/2 This paragraph was deleted.
21.b/2 Reason: The check prevents the returned object (for a nonlimited
type) from outliving the object designated by one of its
discriminants. The check is made on the values of the
discriminants, which may come from the return_subtype_indication
(if constrained), or the expression, but it is never necessary to
check both.
22/2 {AI95-00318-02} For the execution of an extended_return_statement, the
handled_sequence_of_statements is executed. Within this handled_sequence_-
of_statements, the execution of a simple_return_statement that applies to the
extended_return_statement causes a transfer of control that completes the
extended_return_statement. Upon completion of a return statement that applies
to a callable construct, a transfer of control is performed which completes
the execution of the callable construct, and returns to the caller.
23/2 {AI95-00318-02} In the case of a function, the function_call denotes a
constant view of the return object.
Implementation Permissions
24/2 {AI95-00416-01} If the result subtype of a function is unconstrained, and
a call on the function is used to provide the initial value of an object with
a constrained nominal subtype, Constraint_Error may be raised at the point of
the call (after abandoning the execution of the function body) if, while
elaborating the return_subtype_indication or evaluating the expression of a
return statement that applies to the function body, it is determined that the
value of the result will violate the constraint of the subtype of this object.
24.a/2 Reason: Without such a permission, it would be very difficult to
implement "build-in-place" semantics. Such an exception is not
handleable within the function, because in the return-by-copy
case, the constraint check to verify that the result satisfies the
constraints of the object being initialized happens after the
function returns, and we want the semantics to change as little as
possible when switching between return-by-copy and build-in-place.
This implies further that upon detecting such a situation, the
implementation may need to simulate a goto to a point outside any
local exception handlers prior to raising the exception.
24.b/2 Ramification: This permission is allowed during the evaluation of
the expression of an extended_return_statement, because the return_-
subtype_indication may be unconstrained and the expression then
would provide the constraints.
Examples
25 Examples of return statements:
26/2 {AI95-00318-02}
return; -- in a procedure body, entry_body,
-- accept_statement
, or extended_return_statement
27 return Key_Value(Last_Index); -- in a function body
28/2 {AI95-00318-02}
return Node : Cell do -- in a function body, see 3.10.1
for Cell
Node.Value := Result;
Node.Succ := Next_Node;
end return;
Incompatibilities With Ada 83
28.a/2 {AI95-00318-02} {incompatibilities with Ada 83} In Ada 95, if the
result type of a function has a part that is a task, then an
attempt to return a local variable will raise Program_Error. This
is illegal in Ada 2005, see below. In Ada 83, if a function
returns a local variable containing a task, execution is erroneous
according to AI83-00867. However, there are other situations where
functions that return tasks (or that return a variant record only
one of whose variants includes a task) are correct in Ada 83 but
will raise Program_Error according to the new rules.
28.b The rule change was made because there will be more types
(protected types, limited controlled types) in Ada 95 for which it
will be meaningless to return a local variable, and making all of
these erroneous is unacceptable. The current rule was felt to be
the simplest that kept upward incompatibilities to situations
involving returning tasks, which are quite rare.
Wording Changes from Ada 83
28.c This clause has been moved here from chapter 5, since it has
mainly to do with subprograms.
28.d A function now creates an anonymous object. This is necessary so
that controlled types will work.
28.e/2 {AI95-00318-02} We have clarified that a return statement applies
to a callable construct, not to a callable entity.
28.f/2 {AI95-00318-02} There is no need to mention generics in the rules
about where a return statement can appear and what it applies to;
the phrase "body of a subprogram or generic subprogram" is
syntactic, and refers exactly to "subprogram_body".
Incompatibilities With Ada 95
28.g/2 {AI95-00318-02} {incompatibilities with Ada 95} The entire
business about return-by-reference types has been dropped.
Instead, the expression of a return statement of a limited type
can only be an aggregate or function_call (see 7.5). This means
that returning a global object or type_conversion, legal in Ada
95, is now illegal. Such functions can be converted to use
anonymous access return types by adding access in the function
definition and return statement, adding .all in uses, and adding
aliased in the object declarations. This has the advantage of
making the reference return semantics much clearer to the casual
reader.
28.h/2 We changed these rules so that functions, combined with the new
rules for limited types (7.5), can be used as build-in-place
constructors for limited types. This reduces the differences
between limited and nonlimited types, which will make limited
types useful in more circumstances.
Extensions to Ada 95
28.i/2 {AI95-00318-02} {extensions to Ada 95} The
extended_return_statement is new. This provides a name for the
object being returned, which reduces the copying needed to return
complex objects (including no copying at all for limited objects).
It also allows component-by-component construction of the return
object.
Wording Changes from Ada 95
28.j/2 {AI95-00318-02} The wording was updated to support anonymous
access return subtypes.
28.k/2 {AI95-00318-02} The term "return expression" was dropped because
reviewers found it confusing when applied to the default
expression of an extended_return_statement.
28.l/2 {AI95-00344-01} {AI95-00416-01} Added accessibility checks to
class-wide return statements. These checks could not fail in Ada
95 (as all of the types had to be declared at the same level, so
the tagged type would necessarily have been at the same level as
the type of the object).
28.m/2 {AI95-00402-01} {AI95-00416-01} Added accessibility checks to
return statements for types with access discriminants. Since such
types have to be limited in Ada 95, the expression of a return
statement would have been illegal in order for this check to fail.
28.n/2 {AI95-00416-01} Added an Implementation Permission allowing early
raising of Constraint_Error if the result cannot fit in the
ultimate object. This gives implementations more flexibility to do
built-in-place returns, and is essential for limited types (which
cannot be built in a temporary).
6.5.1 Pragma No_Return
1/2 {AI95-00329-01} {AI95-00414-01} A pragma No_Return indicates that a
procedure cannot return normally[; it may propagate an exception or loop
forever].
1.a/2 Discussion: Pragma No_Deposit will have to wait for Ada 2017. :-)
Syntax
2/2 {AI95-00329-01} {AI95-00414-01} The form of a pragma No_Return, which
is a representation pragma (see 13.1), is as follows:
3/2 pragma No_Return(procedure_local_name{, procedure_local_name});
Legality Rules
4/2 {AI95-00329-01} {AI95-00414-01} {non-returning} Each
procedure_local_name shall denote one or more procedures or generic procedures; the
denoted entities are non-returning. The procedure_local_name shall not denote
a null procedure nor an instance of a generic unit.
4.a/2 Reason: A null procedure cannot have the appropriate non-returning
semantics, as it does not raise an exception or loop forever.
4.b/2 Ramification: The procedure can be abstract. The denoted
declaration can be a renaming_declaration if it obeys the usual
rules for representation pragmas: the renaming has to occur
immediately within the same declarative region as the renamed
subprogram. If a non-returning procedure is renamed (anywhere)
calls through the new name still have the non-returning semantics.
5/2 {AI95-00329-01} {AI95-00414-01} A return statement shall not apply to a
non-returning procedure or generic procedure.
6/2 {AI95-00414-01} A procedure shall be non-returning if it overrides a
dispatching non-returning procedure. {generic contract issue [partial]} 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.
6.a/2 Reason: This ensures that dispatching calls to non-returning
procedures will, in fact, not return.
7/2 {AI95-00414-01} If a renaming-as-body completes a non-returning procedure
declaration, then the renamed procedure shall be non-returning.
7.a/2 Reason: This ensures that no extra code is needed to implement the
renames (that is, no wrapper is needed) as the body has the same
property.
Static Semantics
8/2 {AI95-00329-01} {AI95-00414-01} If a generic procedure is non-returning,
then so are its instances. If a procedure declared within a generic unit is
non-returning, then so are the corresponding copies of that procedure in
instances.
Dynamic Semantics
9/2 {AI95-00329-01} {AI95-00414-01} If the body of a non-returning procedure
completes normally, Program_Error is raised at the point of the call.
{Program_Error (raised by failure of run-time check)}
9.a/2 Discussion: Note that there is no name for suppressing this check,
since the check represents a bug, imposes no time overhead, and
minimal space overhead (since it can usually be statically
eliminated as dead code).
9.b/2 Implementation Note: If a non-returning procedure tries to return,
we raise Program_Error. This is stated as happening at the call
site, because we do not wish to allow the procedure to handle the
exception (and then, perhaps, try to return again!). However, the
expected run-time model is that the compiler will generate raise
Program_Error at the end of the procedure body (but not handleable
by the procedure itself), as opposed to doing it at the call site.
(This is just like the typical run-time model for functions that
fall off the end without returning a value). The reason is
indirect calls: in P.all(...);, the compiler cannot know whether P
designates a non-returning procedure or a normal one. Putting the
raise Program_Error in the procedure's generated code solves this
problem neatly.
9.c/2 Similarly, if one passes a non-returning procedure to a generic
formal parameter, the compiler cannot know this at call sites (in
shared code implementations); the raise-in-body solution deals
with this neatly.
Examples
10/2 {AI95-00433-01}
procedure Fail(Msg : String); -- raises Fatal_Error exception
pragma No_Return(Fail);
-- Inform compiler and reader that procedure never returns normally
Extensions to Ada 95
10.a/2 {AI95-00329-01} {AI95-00414-01} {extensions to Ada 95} Pragma
No_Return is new.
6.6 Overloading of Operators
1 {operator} {user-defined operator} {operator (user-defined)} An operator
is a function whose designator is an operator_symbol. [Operators, like other
functions, may be overloaded.]
Name Resolution Rules
2 Each use of a unary or binary operator is equivalent to a function_call
with function_prefix being the corresponding operator_symbol, and with
(respectively) one or two positional actual parameters being the operand(s) of
the operator (in order).
2.a To be honest: We also use the term operator (in Section 4 and in
6.1) to refer to one of the syntactic categories defined in 4.5
, "Operators and Expression Evaluation" whose names end with "
_operator:" logical_operator, relational_operator, binary_adding_-
operator, unary_adding_operator, multiplying_operator, and highest_-
precedence_operator.
Legality Rules
3 The subprogram_specification of a unary or binary operator shall have one
or two parameters, respectively. A generic function instantiation whose
designator is an operator_symbol is only allowed if the specification of the
generic function has the corresponding number of parameters.
4 Default_expressions are not allowed for the parameters of an operator
(whether the operator is declared with an explicit subprogram_specification or
by a generic_instantiation).
5 An explicit declaration of "/=" shall not have a result type of the
predefined type Boolean.
Static Semantics
6 A declaration of "=" whose result type is Boolean implicitly declares a
declaration of "/=" that gives the complementary result.
NOTES
7 8 The operators "+" and "-" are both unary and binary operators, and
hence may be overloaded with both one- and two-parameter functions.
Examples
8 Examples of user-defined operators:
9 function "+" (Left, Right : Matrix) return Matrix;
function "+" (Left, Right : Vector) return Vector;
-- assuming that A, B, and C are of the type Vector
-- the following two statements are equivalent:
A := B + C;
A := "+"(B, C);
Extensions to Ada 83
9.a {extensions to Ada 83} Explicit declarations of "=" are now
permitted for any combination of parameter and result types.
9.b Explicit declarations of "/=" are now permitted, so long as the
result type is not Boolean.
6.7 Null Procedures
1/2 {AI95-00348-01} A null_procedure_declaration provides a shorthand to
declare a procedure with an empty body.
Syntax
2/2 {AI95-00348-01} null_procedure_declaration ::=
[overriding_indicator]
procedure_specification is null;
Static Semantics
3/2 {AI95-00348-01} A null_procedure_declaration declares a null
procedure.{null procedure} {procedure (null)} A completion is not allowed for a
null_procedure_declaration.
3.a/2 Reason: There are no null functions because the return value has
to be constructed somehow; a function that always raises
Program_Error doesn't seem very useful or worth the complication.
Dynamic Semantics
4/2 {AI95-00348-01} The execution of a null procedure is invoked by a
subprogram call. For the execution of a subprogram call on a null procedure,
the execution of the subprogram_body has no effect.
4.a/2 Ramification: Thus, a null procedure is equivalent to the body
4.b/2 begin
null;
end;
4.c/2 with the exception that a null procedure can be used in place of a
procedure specification.
5/2 {AI95-00348-01} {elaboration (null_procedure_declaration) [partial]} The
elaboration of a null_procedure_declaration has no effect.
Examples
6/2 {AI95-00433-01}
procedure Simplify(Expr : in out Expression) is null; -- see 3.9
-- By default, Simplify does nothing, but it may be overridden in extensions of Expression
Extensions to Ada 95
6.a/2 {AI95-00348-01} {extensions to Ada 95} Null procedures are new.
Generated by dwww version 1.15 on Sat May 18 09:47:36 CEST 2024.