Skip to main content

6.3 Subprogram Bodies

danger

This Reference Manual output has not been verified, and may contain omissions or errors. Report any problems on the tracking issue

1

[A subprogram_body specifies the execution of a subprogram.]

Syntax

2/3

subprogram_body ::=
[overriding_indicator]
subprogram_specification
[aspect_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/5

[In contrast to other bodies,] a subprogram_body is allowed to be defined without it being 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.

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

The elaboration of a nongeneric 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

[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

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 nongenerics.

Wording Changes from Ada 95

Extensions to Ada 2005

11.g/3

An optional aspect_specification can be used in a subprogram_body. This is described in 13.1.1.

6.3.1 Conformance Rules

1

[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} [As explained in B.1, “Interfacing Aspects”, 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:

3/3
  • 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)].
3.a
ramification

See also the rule about renamings-as-body in 8.5.4.

4
  • 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
  • a subprogram declared immediately within a protected_body;
  • 10.1/4
  • any prefixed view of a subprogram (see 4.1.3) without synchronization kind (see 9.5) By_Entry or By_Protected_Procedure.
10.a/5
reason

The profile of a prefixed view is different from 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.

10.b/4

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).

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/3

Whenever we wish to disallow the Access attribute in order to ease implementation, we make the subprogram Intrinsic. Several language-defined subprograms have “with 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.

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/4
  • The default calling convention is protected 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.
  • 13/4
  • The default calling convention is entry for an entry and for a prefixed view of a subprogram with a synchronization kind of By_Entry.
  • 13.1/5
  • 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; otherwise, it is the convention of the entity that has the parameter or result, unless that entity has convention protected, entry, or Intrinsic, in which case the convention is Ada.
13.a/2
ramification

The calling convention for other anonymous access-to-subprogram types is Ada.

13.2/1
  • {8652/0011} [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/3

Of these four conventions, only Ada and Intrinsic are allowed as a convention_identifier in the specification of a Convention aspect.

14.a/3
discussion

The names of the protected and entry calling conventions cannot be used in the specification of Convention. Note that protected and entry are reserved words.

15/2

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.

15.a/2
discussion

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

Similarly, for anonymous access-to-subprogram parameters, the designated profiles of the types, not the types themselves, have to be conformant.

16/3

Two profiles are mode conformant if:

16.1/3
  • they are type conformant; and
  • 16.2/3
  • corresponding parameters have identical modes and both or neither are explicitly aliased parameters; and
  • 16.3/3
  • 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.
17/3

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.

17.a
ramification

18/3

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 parameters:

18.1/3
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.

18.b/3
reason

The part about null_exclusions 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.

18.c/3

The parts about access-to-subprogram parameters and results is necessary to prevent such types from having different default_expressions 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.

19

Two expressions are fully conformant if, [after replacing each use of an operator with the equivalent function_call:]

20
21.a/5
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.c.1/3

with A; package B is package A_View renames A; function F_View(X : Integer := 9999) return Boolean renames A.F; end B; 21.d with A, B; use A, B; procedure Main is ...

21.e

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.f/4
discussion

We talk about defining_identifiers and "corresponding declarations" because of the possibility of iterator_specifications occurring within the expressions; each iterator_specification is a separate declaration, which we need to allow, but we do want to require that the defining_identifiers are the same.

21.1/3
  • {8652/0018} each attribute_designator in one is the same as the corresponding attribute_designator in the other; and
  • 22/5
  • each primary 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.
22.a/5
ramification

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.

22.b
ramification

Note that the above definition makes full conformance a transitive relation.

23

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.

24

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

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.

26/5

NOTE Any conformance requirements between aspect_specifications that are part of a profile or known_discriminant_part are defined by the semantics of each particular aspect. In particular, there is no general requirement for aspect_specifications to match in conforming profiles or discriminant parts.

Extensions to Ada 83

26.a

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

26.b/2

{8652/0011} 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.

26.c/2

{8652/0018} Corrigendum: Added wording to ensure that two attributes conform only if they have the same attribute_designator.

26.d/2

Defined the calling convention for anonymous access-to-subprogram types and for prefixed views of subprograms (see 4.1.3).

26.e/2

Defined the conformance of access result types (see 6.1).

26.f/2

Defined the prefixed view profile of subprograms for later use.

26.g/2

Defined the conformance of anonymous access-to-subprogram parameters.

Incompatibilities With Ada 2005

26.h/3
correction

Now require null_exclusions 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.

26.i/3
correction

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.

26.j/3
correction

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

26.k/3

Explicitly aliased parameters are included as part of mode conformance (since it affects the parameter passing mechanism).

Incompatibilities With Ada 2012

26.l/5
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

26.m/4

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

26.n/4

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.

26.o/5

The conformance of literals is tightened up to not assume anything about the value of a user-defined literal.

6.3.2 Inline Expansion of Subprograms

1

[Subprograms may be expanded in line at the call site.]

Paragraphs 2 through 4 were moved to Annex J, “Obsolescent Features”.

Static Semantics

5/3

For a callable entity or a generic subprogram, the following language-defined representation aspect may be specified:

5.1/3

Inline
The type of aspect Inline is Boolean. When aspect Inline is True for a callable entity, inline expansion is desired for all calls to that entity. When aspect Inline is True for a generic subprogram, inline expansion is desired for all calls to all instances of that generic subprogram.
5.2/3
If directly specified, the aspect_definition shall be a static expression. [This aspect is never inherited;] if not directly specified, the aspect is False.
5.a/3

Aspect Description for Inline: For efficiency, Inline calls are requested for a subprogram.

5.b/3
This paragraph was deleted.
5.c/3

This paragraph was deleted. 5.d/3 This paragraph was deleted.

5.e/3
ramification

The meaning of a subprogram can be changed by inline expansion as requested by aspect Inline only in the presence of failing checks (see 11.6).

Implementation Permissions

6/3

For each call, an implementation is free to follow or to ignore the recommendation determined by the Inline aspect.

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 via the Inline aspect, so long as the semantics of the program remains unchanged.

Incompatibilities With Ada 83

7.a/3
This paragraph was deleted.

Extensions to Ada 83

7.b/3
This paragraph was deleted.

Extensions to Ada 95

7.c/3
This paragraph was deleted.

Extensions to Ada 2005

7.d/3

Aspect Inline is new; pragma Inline is now obsolescent.