

                               6   Subprograms


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

2/3 A callable entity is a subprogram or entry (see Section 9). A callable
entity is invoked by a call; that is, a subprogram call or entry call. 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.


6.1 Subprogram Declarations


1   A subprogram_declaration declares a procedure or function.


                                   Syntax

2/3     subprogram_declaration ::= 
            [overriding_indicator]
            subprogram_specification
                [aspect_specification];

3/2     This paragraph was deleted.

4/2     subprogram_specification ::= 
            procedure_specification
          | function_specification

4.1/2   procedure_specification ::= procedure defining_program_unit_name
         parameter_profile

4.2/2   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/3    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 subclause 4.5.

11      defining_operator_symbol ::= operator_symbol

12      parameter_profile ::= [formal_part]

13/2    parameter_and_result_profile ::= 
            [formal_part] return [null_exclusion] subtype_mark
          | [formal_part] return access_definition

14      formal_part ::= 
           (parameter_specification {; parameter_specification})

15/3    parameter_specification ::= 
            defining_identifier_list : [aliased] mode [null_exclusion
        ] subtype_mark [:= default_expression]
          | defining_identifier_list : access_definition
         [:= default_expression]

16      mode ::= [in] | in out | out


                            Name Resolution Rules

17  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. For a formal
parameter, the expected type for its default_expression, if any, is that of
the formal parameter.


                               Legality Rules

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

19  A default_expression is only allowed in a parameter_specification for a
formal parameter of mode in.

20/3 A subprogram_declaration or a generic_subprogram_declaration requires a
completion unless the Import aspect (see B.1) is True for the declaration; the
completion shall be a body or a renaming_declaration (see 8.5). A completion
is not allowed for an abstract_subprogram_declaration (see 3.9.3), a
null_procedure_declaration (see 6.7), or an expression_function_declaration
(see 6.8).

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.


                              Static Semantics

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

23.1/3 An explicitly aliased parameter is a formal parameter whose
parameter_specification includes the reserved word aliased.

24/2 An access parameter is a formal in parameter specified by an
access_definition. 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.

25  The subtypes of a profile are:

26    * For any non-access parameters, the nominal subtype of the parameter.

27/2   * For any access parameters of an access-to-object type, the designated
        subtype of the parameter type.

27.1/3   * For any access parameters of an access-to-subprogram type, the
        subtypes of the designated profile of the parameter type.

28/2   * For any non-access result, the nominal subtype of the function result.

28.1/2   * For any access result type of an access-to-object type, the
        designated subtype of the result type.

28.2/3   * For any access result type of an access-to-subprogram type, the
        subtypes of the designated profile of the result type.

29  The types of a profile are the types of those subtypes.

30/3 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 declared by a
null_procedure_declaration is a null procedure; a procedure declared by a
subprogram_declaration is not. See 6.7, "Null Procedures". Finally, a function
declared by an expression_function_declaration is an expression function; a
function declared by a subprogram_declaration is not. See 6.8, "
Expression Functions".

30.1/2 An overriding_indicator is used to indicate whether overriding is
intended. See 8.3.1, "Overriding Indicators".


                              Dynamic Semantics

31/2 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/4    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
        function Find(B : aliased in out Barrel; Key : String) return Real;
                                                                 --  see 4.1.5

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


6.1.1 Preconditions and Postconditions


1/5 For a noninstance subprogram (including a generic formal subprogram), a
generic subprogram, an entry, or an access-to-subprogram type, the following
language-defined aspects may be specified with an aspect_specification (see
13.1.1):

2/5 Pre         This aspect specifies a specific precondition for a callable
                entity or an access-to-subprogram type; it shall be specified
                by an expression, called a specific precondition expression.
                If not specified for an entity, the specific precondition
                expression for the entity is the enumeration literal True.

3/3 Pre'Class   This aspect specifies a class-wide precondition for an
                operation of a tagged type and its descendants; it shall be
                specified by an expression, called a class-wide precondition
                expression. If not specified for an entity, then if no other
                class-wide precondition applies to the entity, the class-wide
                precondition expression for the entity is the enumeration
                literal True.

4/5 Post        This aspect specifies a specific postcondition for a callable
                entity or an access-to-subprogram type; it shall be specified
                by an expression, called a specific postcondition expression.
                If not specified for an entity, the specific postcondition
                expression for the entity is the enumeration literal True.

5/3 Post'Class  This aspect specifies a class-wide postcondition for an
                operation of a tagged type and its descendants; it shall be
                specified by an expression, called a class-wide postcondition
                expression. If not specified for an entity, the class-wide
                postcondition expression for the entity is the enumeration
                literal True.


                            Name Resolution Rules

6/3 The expected type for a precondition or postcondition expression is any
boolean type.

7/5 Within the expression for a Pre'Class or Post'Class aspect for a primitive
subprogram S of a tagged type T, a name that denotes a formal parameter (or
S'Result) of type T is interpreted as though it had a (notional) nonabstract
type NT that is a formal derived type whose ancestor type is T, with directly
visible primitive operations. Similarly, a name that denotes a formal access
parameter (or S'Result) of type access-to-T is interpreted as having type
access-to-NT. The result of this interpretation is that the only operations
that can be applied to such names are those defined for such a formal derived
type.

8/3 For an attribute_reference with attribute_designator Old, if the attribute
reference has an expected type or shall resolve to a given type, the same
applies to the prefix; otherwise, the prefix shall be resolved independently
of context.


                               Legality Rules

9/3 The Pre or Post aspect shall not be specified for an abstract subprogram
or a null procedure. Only the Pre'Class and Post'Class aspects may be
specified for such a subprogram.

10/3 If a type T has an implicitly declared subprogram P inherited from a
parent type T1 and a homograph (see 8.3) of P from a progenitor type T2, and

11/3   * the corresponding primitive subprogram P1 of type T1 is neither null
        nor abstract; and

12/3   * the class-wide precondition expression True does not apply to P1
        (implicitly or explicitly); and

13/3   * there is a class-wide precondition expression that applies to the
        corresponding primitive subprogram P2 of T2 that does not fully
        conform to any class-wide precondition expression that applies to P1,

14/3 then:

15/3   * If the type T is abstract, the implicitly declared subprogram P is
        abstract.

16/3   * Otherwise, the subprogram P requires overriding and shall be
        overridden with a nonabstract subprogram.

17/3 If a renaming of a subprogram or entry S1 overrides an inherited
subprogram S2, then the overriding is illegal unless each class-wide
precondition expression that applies to S1 fully conforms to some class-wide
precondition expression that applies to S2 and each class-wide precondition
expression that applies to S2 fully conforms to some class-wide precondition
expression that applies to S1.

17.1/4 Pre'Class shall not be specified for an overriding primitive subprogram
of a tagged type T unless the Pre'Class aspect is specified for the
corresponding primitive subprogram of some ancestor of T.

17.2/4 In addition to the places where Legality Rules normally apply (see
12.3), these rules also apply in the private part of an instance of a generic
unit.


                              Static Semantics

18/5 If a Pre'Class or Post'Class aspect is specified for a primitive
subprogram S of a tagged type T, or such an aspect defaults to True, then a
corresponding expression also applies to the corresponding primitive
subprogram S of each descendant of T (including T itself). The corresponding
expression is constructed from the associated expression as follows:

18.1/4   * References to formal parameters of S (or to S itself) are replaced
        with references to the corresponding formal parameters of the
        corresponding inherited or overriding subprogram S (or to the
        corresponding subprogram S itself).

18.2/4 The primitive subprogram S is illegal if it is not abstract and the
corresponding expression for a Pre'Class or Post'Class aspect would be illegal.

19/5 If performing checks is required by the Pre, Pre'Class, Post, or
Post'Class assertion policies (see 11.4.2) in effect at the point of a
corresponding aspect specification applicable to a given subprogram, entry, or
access-to-subprogram type, then the respective precondition or postcondition
expressions are considered enabled.

20/5 A subexpression of a postcondition expression is known on entry if it is
any of:

21/5   * a static subexpression (see 4.9);

22/5   * a literal whose type does not have any Integer_Literal, Real_Literal,
        or String_Literal aspect specified, or the function specified by such
        an attribute has aspect Global specified to be null;

22.1/5   * a name statically denoting a full constant declaration of a type
        for which all views are constant (see 3.3);

22.2/5   * a name statically denoting a nonaliased in parameter of an
        elementary type;

22.3/5   * an Old attribute_reference;

22.4/5   * an invocation of a predefined operator where all of the operands
        are known on entry;

22.5/5   * a function call where the function has aspect Global => null where
        all of the actual parameters are known on entry;

22.6/5   * a selected_component of a known-on-entry prefix;

22.7/5   * an indexed_component of a known-on-entry prefix where all index
        expressions are known on entry;

22.8/5   * a parenthesized known-on-entry expression;

22.9/5   * a qualified_expression or type_conversion whose operand is a
        known-on-entry expression;

22.10/5   * a conditional_expression where all of the conditions,
        selecting_expressions, and dependent_expressions are known on entry.

22.11/5 A subexpression of a postcondition expression is unconditionally
evaluated, conditionally evaluated, or repeatedly evaluated. The following
subexpressions are repeatedly evaluated:

22.12/5   * A subexpression of a predicate of a quantified_expression;

22.13/5   * A subexpression of the expression of an
        array_component_association;

22.14/5   * A subexpression of the expression of a
        container_element_association.

22.15/5 If a subexpression is not repeatedly evaluated, and not evaluated
unconditionally, then it is conditionally evaluated, and there is a set of
determining expressions that determine whether the subexpression is actually
evaluated at run time. Such subexpressions and their determining expressions
are as follows:

22.16/5   * For an if_expression that is not repeatedly evaluated, a
        subexpression of any part other than the first condition is
        conditionally evaluated, and its determining expressions include all
        conditions of the if_expression that precede the subexpression
        textually;

22.17/5   * For a case_expression that is not repeatedly evaluated, a
        subexpression of any dependent_expression is conditionally evaluated,
        and its determining expressions include the selecting_expression of
        the case_expression;

23/5   * For a short-circuit control form that is not repeatedly evaluated, a
        subexpression of the right-hand operand is conditionally evaluated,
        and its determining expressions include the left-hand operand of the
        short-circuit control form;

24/5   * For a membership test that is not repeatedly evaluated, a
        subexpression of a membership_choice other than the first is
        conditionally evaluated, and its determining expressions include the
        tested_simple_expression and the preceding membership_choices of the
        membership test.

24.1/5 A conditionally evaluated subexpression is determined to be unevaluated
at run time if its set of determining expressions are all known on entry, and
when evaluated on entry their values are such that the given subexpression is
not evaluated.

25/3 For a prefix X that denotes an object of a nonlimited type, the following
attribute is defined:

26/5 X'Old      Each X'Old in a postcondition expression that is enabled,
                other than those that occur in subexpressions that are
                determined to be unevaluated, denotes a constant that is
                implicitly declared at the beginning of the subprogram body,
                entry body, or accept statement.

26.1/4          The implicitly declared entity denoted by each occurrence of
                X'Old is declared as follows:

26.2/4            * If X is of an anonymous access type defined by an
                    access_definition A then

26.3/4                  X'Old : constant A := X;

26.4/4            * If X is of a specific tagged type T then

26.5/4                  anonymous : constant T'Class := T'Class(X);
                        X'Old : T renames T(anonymous);

26.6/4              where the name X'Old denotes the object renaming.

26.7/4            * Otherwise

26.8/4                  X'Old : constant S := X;

26.9/4              where S is the nominal subtype of X. This includes the
                    case where the type of S is an anonymous array type or a
                    universal type.

26.10/5         The type and nominal subtype of X'Old is as implied by the
                above definitions.

27/5            Reference to this attribute is only allowed within a
                postcondition expression. The prefix of an Old
                attribute_reference shall not contain a Result
                attribute_reference, nor an Old attribute_reference, nor a use
                of an entity declared within the postcondition expression but
                not within prefix itself (for example, the loop parameter of
                an enclosing quantified_expression). The prefix of an Old
                attribute_reference shall statically name (see 4.9) an entity,
                unless the attribute_reference is unconditionally evaluated,
                or is conditionally evaluated where all of the determining
                expressions are known on entry.

28/5 For a prefix F that denotes a function declaration or an
access-to-function type, the following attribute is defined:

29/5 F'Result   Within a postcondition expression for F, denotes the return
                object of the function call for which the postcondition
                expression is evaluated. The type of this attribute is that of
                the result subtype of the function or access-to-function type
                except within a Post'Class postcondition expression for a
                function with a controlling result or with a controlling
                access result; in those cases the type of the attribute was
                described previously.

30/3            Use of this attribute is allowed only within a postcondition
                expression for F.

30.1/5 For a prefix E that denotes an entry declaration of an entry family
(see 9.5.2), the following attribute is defined:

30.2/5 E'Index  Within a precondition or postcondition expression for entry
                family E, denotes the value of the entry index for the call of
                E. The nominal subtype of this attribute is the entry index
                subtype.

30.3/5          Use of this attribute is allowed only within a precondition or
                postcondition expression for E.


                              Dynamic Semantics

31/3 Upon a call of the subprogram or entry, after evaluating any actual
parameters, precondition checks are performed as follows:

32/3   * The specific precondition check begins with the evaluation of the
        specific precondition expression that applies to the subprogram or
        entry, if it is enabled; if the expression evaluates to False,
        Assertions.Assertion_Error is raised; if the expression is not
        enabled, the check succeeds.

33/3   * The class-wide precondition check begins with the evaluation of any
        enabled class-wide precondition expressions that apply to the
        subprogram or entry. If and only if all the class-wide precondition
        expressions evaluate to False, Assertions.Assertion_Error is raised.

34/5 The precondition checks are performed in an arbitrary order, and if any
of the class-wide precondition expressions evaluate to True, it is not
specified whether the other class-wide precondition expressions are evaluated.
The precondition checks and any check for elaboration of the subprogram body
are performed in an arbitrary order. In a call on a protected operation, the
checks are performed before starting the protected action. For an entry call,
the checks are performed prior to checking whether the entry is open.

35/3 Upon successful return from a call of the subprogram or entry, prior to
copying back any by-copy in out or out parameters, the postcondition check is
performed. This consists of the evaluation of any enabled specific and
class-wide postcondition expressions that apply to the subprogram or entry. If
any of the postcondition expressions evaluate to False, then
Assertions.Assertion_Error is raised. The postcondition expressions are
evaluated in an arbitrary order, and if any postcondition expression evaluates
to False, it is not specified whether any other postcondition expressions are
evaluated. The postcondition check, and any constraint or predicate checks
associated with in out or out parameters are performed in an arbitrary order.

35.1/4 For a call to a task entry, the postcondition check is performed before
the end of the rendezvous; for a call to a protected operation, the
postcondition check is performed before the end of the protected action of the
call. The postcondition check for any call is performed before the
finalization of any implicitly-declared constants associated (as described
above) with Old attribute_references but after the finalization of any other
entities whose accessibility level is that of the execution of the callable
construct.

36/3 If a precondition or postcondition check fails, the exception is raised
at the point of the call; the exception cannot be handled inside the called
subprogram or entry. Similarly, any exception raised by the evaluation of a
precondition or postcondition expression is raised at the point of call.

37/4 For any call to a subprogram or entry S (including dispatching calls),
the checks that are performed to verify specific precondition expressions and
specific and class-wide postcondition expressions are determined by those for
the subprogram or entry actually invoked. Note that the class-wide
postcondition expressions verified by the postcondition check that is part of
a call on a primitive subprogram of type T includes all class-wide
postcondition expressions originating in any progenitor of T, even if the
primitive subprogram called is inherited from a type T1 and some of the
postcondition expressions do not apply to the corresponding primitive
subprogram of T1. Any operations within a class-wide postcondition expression
that were resolved as primitive operations of the (notional) formal derived
type NT, are in the evaluation of the postcondition bound to the corresponding
operations of the type identified by the controlling tag of the call on S.
This applies to both dispatching and non-dispatching calls on S.

38/4 The class-wide precondition check for a call to a subprogram or entry S
consists solely of checking the class-wide precondition expressions that apply
to the denoted callable entity (not necessarily to the one that is invoked).
Any operations within such an expression that were resolved as primitive
operations of the (notional) formal derived type NT are in the evaluation of
the precondition bound to the corresponding operations of the type identified
by the controlling tag of the call on S. This applies to both dispatching and
non-dispatching calls on S.

38.1/5 For the purposes of the above rules, a call on an inherited subprogram
is considered to involve a call on a subprogram S' whose body consists only of
a call (with appropriate conversions) on the non-inherited subprogram S from
which the inherited subprogram was derived. It is not specified whether
class-wide precondition or postcondition expressions that are equivalent (with
respect to which non-inherited function bodies are executed) for S and S' are
evaluated once or twice. If evaluated only once, the value returned is used
for both associated checks.

39/5 For a call via an access-to-subprogram value, precondition and
postcondition checks performed are as determined by the subprogram or entry
denoted by the prefix of the Access attribute reference that produced the
value. In addition, a precondition check of any precondition expression
associated with the access-to-subprogram type is performed. Similarly, a
postcondition check of any postcondition expression associated with the
access-to-subprogram type is performed.

40/5 For a call on a generic formal subprogram, precondition and postcondition
checks performed are as determined by the subprogram or entry denoted by the
actual subprogram, along with any specific precondition and specific
postcondition of the formal subprogram itself.


                         Implementation Permissions

41/5 An implementation may evaluate a known-on-entry subexpression of a
postcondition expression of an entity at the place where X'Old constants are
created for the entity, with the normal evaluation of the postcondition
expression, or both.

        NOTES

42/3    5  A precondition is checked just before the call. If another task can
        change any value that the precondition expression depends on, the
        precondition need not hold within the subprogram or entry body.

43/5    6  For an example of the use of these aspects and attributes, see the
        Streams Subsystem definitions in 13.13.1.


6.1.2 The Global and Global'Class Aspects


1/5 For a subprogram, an entry, a named access-to-subprogram type, a task
unit, a protected unit, or a library package or generic library package, the
following language-defined aspect may be specified with an
aspect_specification (see 13.1.1):

2/5 Global      The syntax for the aspect_definition used to define a Global
                aspect is as follows:

3/5             global_aspect_definition ::= 
                    null
                  | Unspecified
                  | global_mode global_designator
                  | (global_aspect_element{, global_aspect_element})
                  | extended_global_aspect_definition

4/5             global_aspect_element ::= 
                    global_mode global_set
                  | extended_global_aspect_element

5/5             global_mode ::= 
                    basic_global_mode
                  | extended_global_mode

6/5             basic_global_mode ::= in | in out | out

7/5             global_set ::= global_name {, global_name}

8/5             global_designator ::= all | synchronized | global_name

9/5             global_name ::= object_name | package_name

10/5            The Global aspect identifies the set of variables (which, for
                the purposes of this clause includes all constants with some
                part being immutably limited, or of a controlled type, private
                type, or private extension) that are global to a callable
                entity or task body, and that are read or updated as part of
                the execution of the callable entity or task body. If
                specified for a protected unit, it refers to all of the
                protected operations of the protected unit. Constants of any
                type may also be mentioned in a Global aspect.

11/5            If not specified or otherwise defined below, the aspect
                defaults to the Global aspect for the enclosing library unit
                if the entity is declared at library level, and to Unspecified
                otherwise. If not specified for a library unit, the aspect
                defaults to Global => null for a library unit that is declared
                Pure, and to Global => Unspecified otherwise.

12/5 For a dispatching subprogram, the following language-defined aspect may
be specified with an aspect_specification (see 13.1.1):

13/5 Global'Class
                The syntax for the aspect_definition used to define a
                Global'Class aspect is the same as that defined above for
                global_aspect_definition. This aspect identifies an upper
                bound on the set of variables global to a dispatching
                operation that can be read or updated as a result of a
                dispatching call on the operation. If not specified, the
                aspect defaults to the Global aspect for the dispatching
                subprogram.


                            Name Resolution Rules

14/5 A global_name shall resolve to statically denote an object or a package
(including a limited view of a package).


                              Static Semantics

15/5 A global_aspect_definition defines the Global or Global'Class aspect of
some entity. The Global aspect identifies the sets of global variables that
can be read, written, or modified as a side effect of executing the
operation(s) associated with the entity. The Global'Class aspect associated
with a dispatching operation of type T represents a restriction on the Global
aspect on a corresponding operation of any descendant of type T.

16/5 The Global aspect for a callable entity defines the global variables that
might be referenced as part of a call on the entity, including any assertion
expressions that might be evaluated as part of the call, including
preconditions, postconditions, predicates, and type invariants.

17/5 The Global aspect for an access-to-subprogram object (or subtype)
identifies the global variables that might be referenced when calling via the
object (or any object of that subtype) including assertion expressions that
apply.

18/5 For a predefined operator of an elementary type, or the function
representing an enumeration literal, the Global aspect is null. For a
predefined operator of a composite type, the Global aspect of the operator
defaults to that of the enclosing library unit (unless a Global aspect is
specified for the type - see H.7).

19/5 The following is defined in terms of operations; the rules apply to all
of the above kinds of entities.

20/5 The global variables associated with any global_mode can be read as a
side effect of an operation. The in out and out global_modes together identify
the set of global variables that can be updated as a side effect of an
operation. Creating an access-to-variable value that designates an object is
considered an update of the designated object, and creating an
access-to-constant value that designates an object is considered a read of the
designated object.

21/5 The overall set of objects associated with each global_mode includes all
objects identified for the mode in the global_aspect_definition.

22/5 A global_set identifies a global variable set as follows:

23/5   * all identifies the set of all global variables;

24/5   * synchronized identifies the set of all synchronized variables (see
        9.10), as well as variables of a composite type all of whose
        non-discriminant subcomponents are synchronized;

25/5   * global_name{, global_name} identifies the union of the sets of
        variables identified by the global_names in the list, for the
        following forms of global_name:

26/5      * object_name identifies the specified global variable (or constant);

27/5      * package_name identifies the set of all variables declared in the
            private part or body of the package, or anywhere within a private
            descendant of the package.


                               Legality Rules

28/5 Within a global_aspect_definition, a given global_mode shall be specified
at most once. Similarly, within a global_aspect_definition, a given entity
shall be named at most once by a global_name.

29/5 If an entity (other than a library package or generic library package)
has a Global aspect other than Unspecified or in out all, then the associated
operation(s) shall read only those variables global to the entity that are
within the global variable set associated with the in, in out, or out
global_modes, and the operation(s) shall update only those variables global to
the entity that are within the global variable set associated with either the
in out or out global_modes. In the absence of the No_Hidden_Indirect_Globals
restriction (see H.4), this ignores objects reached via a dereference of an
access value. The above rule includes any possible Global effects of calls
occurring during the execution of the operation, except for the following
excluded calls:

30/5   * calls to formal subprograms;

31/5   * calls associated with operations on formal subtypes;

32/5   * calls through formal objects of an access-to-subprogram type;

33/5   * calls through access-to-subprogram parameters;

34/5   * calls on operations with Global aspect Unspecified.

35/5 The possible Global effects of these excluded calls (other than those
that are Unspecified) are taken into account by the caller of the original
operation, by presuming they occur at least once during its execution. For
calls that are not excluded, the possible Global effects of the call are those
permitted by the Global aspect of the associated entity, or by its
Global'Class aspect if a dispatching call.

36/5 If a Global aspect other than Unspecified or in out all applies to an
access-to-subprogram type, then the prefix of an Access attribute_reference
producing a value of such a type shall denote a subprogram whose Global aspect
is not Unspecified and is covered by that of the result type, where a global
aspect G1 is covered by a global aspect G2 if the set of variables that G1
identifies as readable or updatable is a subset of the corresponding set for
G2. Similarly on a conversion to such a type, the operand shall be of a named
access-to-subprogram type whose Global aspect is covered by that of the target
type.

37/5 If an implementation-defined global_mode applies to a given set of
variables, an implementation-defined rule determines what sort of references
to them are permitted.

38/5 For a subprogram that is a dispatching operation of a tagged type T, each
mode of its Global aspect shall identify a subset of the variables identified
by the corresponding mode, or by the in out mode, of the Global'Class aspect
of a corresponding dispatching subprogram of any ancestor of T, unless the
aspect of that ancestor is Unspecified.


                         Implementation Permissions

39/5 Implementations need not require that references to a constant object
that are considered variables in the above rules, be accounted for by the
Global or Global'Class aspect, if the implementation can determine that the
constant object is immutable.

40/5 Implementations may perform additional checks on calls to operations with
an Unspecified Global aspect to ensure that they do not violate any
limitations associated with the point of call.

41/5 Implementations may extend the syntax or semantics of the Global aspect
in an implementation-defined manner; for example, supporting additional
global_modes.

        NOTES

42/5    7  For an example of the use of these aspects and attributes, see the
        Vector container definition in A.18.2.


6.2 Formal Parameter Modes


1   A parameter_specification declares a formal parameter of mode in, in out,
or out.


                              Static Semantics

2   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/3 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, unless the formal parameter is explicitly
aliased.

4   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/3   * an explicitly limited record type;

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/5 A parameter of a by-reference type is passed by reference, as is an
explicitly aliased parameter of any type. Each value of a by-reference type
has an associated object. For a value conversion, the associated object is the
anonymous result object if such an object is created (see 4.6); otherwise it
is the associated object of the operand. In other cases, the object associated
with the evaluated operative constituent of the name or expression (see 4.4)
determines its associated object.

11/3 For other parameters, it is unspecified whether the parameter is passed
by copy or by reference.


                          Bounded (Run-Time) Errors

12/3 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 and is not an explicitly aliased parameter, 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). 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.

        NOTES

13/4    8  The mode of a formal parameter describes the direction of
        information transfer to or from the subprogram_body (see 6.1).

14      9  A formal parameter of mode in is a constant view (see 3.3); it
        cannot be updated within the subprogram_body.

15/4    10  A formal parameter of mode out might be uninitialized at the start
        of the subprogram_body (see 6.4.1).


6.3 Subprogram Bodies


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


                              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.

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;


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 As explained in B.1, "Interfacing Aspects", 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/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).

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;

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.

11      The Access attribute is not allowed for Intrinsic subprograms.

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.2/1   * 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.

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

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.

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.

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   * they have the same names; and

18.2/3   * both or neither have null_exclusions; and

18.3/3   * neither have default_expressions, or they both have
        default_expressions that are fully conformant with one another; and

18.4/3   * for access-to-subprogram parameters, the designated profiles are
        fully conformant.

19  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

20.1/4   * corresponding defining_identifiers occurring within the two
        expressions are the same; and

21/4   * 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, or they denote corresponding declarations
        occurring within the two expressions; and

21.1/3   * 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.

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


                         Implementation Permissions

25  An implementation may declare an operator declared in a language-defined
library unit to be intrinsic.


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.


                         Implementation Permissions

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


6.4 Subprogram Calls


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


                            Name Resolution Rules

8/2 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.

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 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.1/2 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 The exception Program_Error is raised at the point of a function_call if
the function completes normally without executing a return statement.

12/2 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.


                                  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/3    procedure Pair(Left, Right : in Person_Name := new Person(M));   --  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/3    Pair;
        Pair(Left => new Person(F), Right => new Person(M));

        NOTES

24      11  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


6.4.1 Parameter Associations


1   A parameter association defines the association between an actual
parameter and a formal parameter.


                            Name Resolution Rules

2/3 The formal_parameter_selector_name of a named parameter_association shall
resolve to denote a parameter_specification of the view being called; this is
the formal parameter of the association. The formal parameter for a positional
parameter_association is the parameter with the corresponding position in the
formal part of the view being called.

3   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. The expected type for an actual parameter is the type of the
corresponding formal parameter.

4   If the mode is in, the actual is interpreted as an expression; otherwise,
the actual is interpreted only as a name, if possible.


                               Legality Rules

5   If the mode is in out or out, the actual shall be a name that denotes a
variable.

5.1/4 If the mode is out, the actual parameter is a view conversion, and the
type of the formal parameter is an access type or a scalar type that has the
Default_Value aspect specified, then

5.2/4   * there shall exist a type (other than a root numeric type) that is an
        ancestor of both the target type and the operand type; and

5.3/4   * in the case of a scalar type, the type of the operand of the
        conversion shall have the Default_Value aspect specified.

5.4/4 In addition to the places where Legality Rules normally apply (see
12.3), these rules also apply in the private part of an instance of a generic
unit.

6/3 If the formal parameter is an explicitly aliased parameter, the type of
the actual parameter shall be tagged or the actual parameter shall be an
aliased view of an object. Further, if the formal parameter subtype F is
untagged:

6.1/3   * the subtype F shall statically match the nominal subtype of the
        actual object; or

6.2/3   * the subtype F shall be unconstrained, discriminated in its full
        view, and unconstrained in any partial view.

6.3/4 In addition to the places where Legality Rules normally apply (see
12.3), these rules also apply in the private part of an instance of a generic
unit.

6.4/3 In a function call, the accessibility level of the actual object for
each explicitly aliased parameter shall not be statically deeper than the
accessibility level of the master of the call (see 3.10.2).

6.5/3 Two names are known to denote the same object if:

6.6/3   * both names statically denote the same stand-alone object or
        parameter; or

6.7/3   * both names are selected_components, their prefixes are known to
        denote the same object, and their selector_names denote the same
        component; or

6.8/3   * both names are dereferences (implicit or explicit) and the
        dereferenced names are known to denote the same object; or

6.9/3   * both names are indexed_components, their prefixes are known to
        denote the same object, and each of the pairs of corresponding index
        values are either both static expressions with the same static value
        or both names that are known to denote the same object; or

6.10/3   * both names are slices, their prefixes are known to denote the same
        object, and the two slices have statically matching index constraints;
        or

6.11/3   * one of the two names statically denotes a renaming declaration
        whose renamed object_name is known to denote the same object as the
        other, the prefix of any dereference within the renamed object_name is
        not a variable, and any expression within the renamed object_name
        contains no references to variables nor calls on nonstatic functions.

6.12/3 Two names are known to refer to the same object if

6.13/3   * The two names are known to denote the same object; or

6.14/3   * One of the names is a selected_component, indexed_component, or
        slice and its prefix is known to refer to the same object as the other
        name; or

6.15/3   * One of the two names statically denotes a renaming declaration
        whose renamed object_name is known to refer to the same object as the
        other name.

6.16/3 If a call C has two or more parameters of mode in out or out that are
of an elementary type, then the call is legal only if:

6.17/5   * For each name N denoting an object of an elementary type that is
        passed as a parameter of mode in out or out to the call C, there is no
        other name among the other parameters of mode in out or out to C that
        is known to denote the same object.

6.18/3 If a construct C has two or more direct constituents that are names or
expressions whose evaluation may occur in an arbitrary order, at least one of
which contains a function call with an in out or out parameter, then the
construct is legal only if:

6.19/3   * For each name N that is passed as a parameter of mode in out or out
        to some inner function call C2 (not including the construct C itself),
        there is no other name anywhere within a direct constituent of the
        construct C other than the one containing C2, that is known to refer
        to the same object.

6.20/3 For the purposes of checking this rule:

6.21/3   * For an array aggregate, an expression associated with a
        discrete_choice_list that has two or more discrete choices, or that
        has a nonstatic range, is considered as two or more separate
        occurrences of the expression;

6.22/3   * For a record aggregate:

6.23/3    * The expression of a record_component_association is considered to
            occur once for each associated component; and

6.24/3    * The default_expression for each record_component_association with
            <> for which the associated component has a default_expression is
            considered part of the aggregate;

6.25/3   * For a call, any default_expression evaluated as part of the call is
        considered part of the call.


                              Dynamic Semantics

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

11    * 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.

12    * For an out parameter that is passed by copy, the formal parameter
        object is created, and:

13/3      * For an access type, the formal parameter is initialized from the
            value of the actual, without checking that the value satisfies any
            constraint, any predicate, or any exclusion of the null value;

13.1/4    * For a scalar type that has the Default_Value aspect specified, the
            formal parameter is initialized from the value of the actual,
            without checking that the value satisfies any constraint or any
            predicate. Furthermore, if the actual parameter is a view
            conversion and either

13.2/4        * there exists no type (other than a root numeric type) that is
                an ancestor of both the target type and the type of the
                operand of the conversion; or

13.3/4        * the Default_Value aspect is unspecified for the type of the
                operand of the conversion

13.4/4      then Program_Error is raised;

14/5      * 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, except that no
            predicate check is performed.

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.1/3   * In a function call, for each explicitly aliased parameter, a check
        is made that the accessibility level of the master of the actual
        object is not deeper than that of the master of the call (see 3.10.2
        ).

16  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  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. These conversions and assignments occur in an arbitrary order.


                             Erroneous Execution

18/3 If the nominal subtype of a formal parameter with discriminants is
constrained or indefinite, and the parameter is passed by reference, then the
execution of the call is erroneous if the value of any discriminant of the
actual is changed while the formal parameter exists (that is, before leaving
the corresponding callable construct).


6.5 Return Statements


1/2 A simple_return_statement or extended_return_statement (collectively
called a return statement) is used to complete the execution of the innermost
enclosing subprogram_body, entry_body, or accept_statement.


                                   Syntax

2/2     simple_return_statement ::= return [expression];

2.1/3   extended_return_object_declaration ::= 
            defining_identifier
         : [aliased][constant] return_subtype_indication [:= expression]

2.2/3   extended_return_statement ::= 
            return extended_return_object_declaration [do
                handled_sequence_of_statements
            end return];

2.3/2   return_subtype_indication ::= subtype_indication
         | access_definition


                            Name Resolution Rules

3/5 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. The expected type for the expression,
if any, of a simple_return_statement is the result type of the corresponding
function. The expected type for the expression of an
extended_return_object_declaration is that of the return_subtype_indication.


                               Legality Rules

4/2 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/5 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. An
extended_return_object_declaration with the reserved word constant shall
include an expression.

5.1/5 The expression of an extended_return_statement is the expression of the
extended_return_object_declaration of the extended_return_statement.

5.2/2 For an extended_return_statement that applies to a function body:

5.3/5   * 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 covered by the result type of the
        function. The subtype defined by the subtype_indication shall be
        statically compatible with the result subtype of the function; if the
        result type of the function is elementary, the two subtypes shall
        statically match. If the result subtype of the function is indefinite,
        then the subtype defined by the subtype_indication shall be a definite
        subtype, or there shall be an expression.

5.4/5   * 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.5/5   * If the result subtype of the function is class-wide, the
        accessibility level of the type of the subtype defined by the
        return_subtype_indication shall not be statically deeper than that of
        the master that elaborated the function body.

5.6/5 For any return statement that applies to a function body:

5.7/5   * If the result subtype of the function is limited, then the
        expression of the return statement (if any) shall meet the
        restrictions described in 7.5.

5.8/5   * If the result subtype of the function is class-wide, the
        accessibility level of the type of the expression (if any) of the
        return statement shall not be statically deeper than that of the
        master that elaborated the function body.

5.9/5   * If the subtype determined by the expression of the
        simple_return_statement or by the return_subtype_indication has one or
        more access discriminants, the accessibility level of the anonymous
        access type of each access discriminant shall not be statically deeper
        than that of the master that elaborated the function body.

5.10/5 If the keyword aliased is present in an
extended_return_object_declaration, the type of the extended return object
shall be immutably limited.


                              Static Semantics

5.11/5 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. An extended_return_statement with the reserved word
constant is a full constant declaration that declares the return object to be
a constant object.


                              Dynamic Semantics

5.12/5 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); 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. A check is made that the value of the
return object belongs to the function result subtype. Constraint_Error is
raised if this check fails.

6/2 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.

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

8/4 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, unless
the return object is defined by an extended_return_object_declaration with a
subtype_indication that is specific, in which case it is that of the type of
the subtype_indication. A check is made that the master of the type identified
by the tag of the result includes the elaboration of the master that
elaborated the function body. If this check fails, Program_Error is raised.

8.1/5 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 by the normal completion of a simple_return_statement or by reaching
the end return of an extended_return_statement, a transfer of control is
performed which completes the execution of the callable construct, and returns
to the caller.

8.2/5 If the result subtype of the function is defined by an
access_definition designating a specific tagged type T, a check is made that
the result value is null or the tag of the object designated by the result
value identifies T. Constraint_Error is raised if this check fails.

Paragraphs 9 through 20 were deleted.

21/3 If any part of the specific type of the return object of a function (or
coextension thereof) has one or more access discriminants whose value is not
constrained by the result subtype of the function, 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 return
statement, is not deeper than the level of the master of the call (see
3.10.2). If this check fails, Program_Error is raised.

22/5 A check is performed that the return value satisfies the predicates of
the return subtype. If this check fails, the effect is as defined in subclause
3.2.4, "Subtype Predicates".

23/2 In the case of a function, the function_call denotes a constant view of
the return object.


                         Implementation Permissions

24/3 For a function call used to initialize a composite object with a
constrained nominal subtype or used to initialize a return object that is
built in place into such an object:

24.1/3   * If the result subtype of the function is constrained, and
        conversion of an object of this subtype to the subtype of the object
        being initialized would raise Constraint_Error, then Constraint_Error
        may be raised before calling the function.

24.2/3   * If the result subtype of the function is unconstrained, and a
        return statement is executed such that the return object is known to
        be constrained, and conversion of the return object to the subtype of
        the object being initialized would raise Constraint_Error, then
        Constraint_Error may be raised at the point of the call (after
        abandoning the execution of the function body).


                                  Examples

25  Examples of return statements:

26/2    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    return Node : Cell do           -- in a function body, see 3.10.1
         for Cell
           Node.Value := Result;
           Node.Succ := Next_Node;
        end return;


6.5.1 Nonreturning Subprograms


1/5 Specifying aspect No_Return to have the value True indicates that a
subprogram cannot return normally; it may propagate an exception or loop
forever.

Paragraphs 2 and 3 were moved to Annex J, "Obsolescent Features".


                              Static Semantics

3.1/5 For a subprogram or generic subprogram, the following language-defined
representation aspect may be specified:

3.2/3 No_Return The type of aspect No_Return is Boolean. When aspect No_Return
                is True for an entity, the entity is said to be nonreturning.

3.3/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.

3.4/5 If a generic subprogram is nonreturning, then so are its instances. If a
subprogram declared within a generic unit is nonreturning, then so are the
corresponding copies of that subprogram in instances.


                               Legality Rules

4/3 Aspect No_Return shall not be specified for a null procedure nor an
instance of a generic unit.

5/2 A return statement shall not apply to a nonreturning procedure or generic
procedure.

5.1/5 Any return statement that applies to a nonreturning function or generic
function shall be a simple_return_statement with an expression that is a
raise_expression, a call on a nonreturning function, or a parenthesized
expression of one of these.

6/5 A subprogram shall be nonreturning if it overrides a dispatching
nonreturning subprogram. 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.

7/5 If a renaming-as-body completes a nonreturning subprogram declaration,
then the renamed subprogram shall be nonreturning.

Paragraph 8 was deleted.


                              Dynamic Semantics

9/2 If the body of a nonreturning procedure completes normally, Program_Error
is raised at the point of the call.


                                  Examples

10/3    procedure Fail(Msg : String)  -- raises Fatal_Error exception
           with No_Return;
           -- Inform compiler and reader that procedure never returns normally


6.6 Overloading of Operators


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


                               Legality Rules

3/3 The subprogram_specification of a unary or binary operator shall have one
or two parameters, respectively. The parameters shall be of mode in. 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, and they are all of mode in.

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/3 An explicit declaration of "=" whose result type is Boolean implicitly
declares an operator "/=" that gives the complementary result.

        NOTES

7       12  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);


6.7 Null Procedures


1/2 A null_procedure_declaration provides a shorthand to declare a procedure
with an empty body.


                                   Syntax

2/3     null_procedure_declaration ::= 
           [overriding_indicator]
           procedure_specification is null
               [aspect_specification];


                               Legality Rules

2.1/3 If a null_procedure_declaration is a completion, it shall be the
completion of a subprogram_declaration or generic_subprogram_declaration. The
profile of a null_procedure_declaration that completes a declaration shall
conform fully to that of the declaration.


                              Static Semantics

3/3 A null_procedure_declaration declares a null procedure. A completion is
not allowed for a null_procedure_declaration; however, a
null_procedure_declaration can complete a previous declaration.


                              Dynamic Semantics

4/2 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.

5/3 The elaboration of a null_procedure_declaration has no other effect than
to establish that the null procedure can be called without failing the
Elaboration_Check.


                                  Examples

6/2     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


6.8 Expression Functions


1/3 An expression_function_declaration provides a shorthand to declare a
function whose body consists of a single return statement.


                                   Syntax

2/4     expression_function_declaration ::= 
           [overriding_indicator]
           function_specification is
               (expression)
               [aspect_specification];
         | [overriding_indicator]
           function_specification is
               aggregate
               [aspect_specification];


                            Name Resolution Rules

3/4 The expected type for the expression or aggregate of an expression_-
function_declaration is the result type (see 6.5) of the function.


                              Static Semantics

3.1/5 An expression_function_declaration declares an expression function. The
return expression of an expression function is the expression or aggregate of
the expression_function_declaration. A completion is not allowed for an
expression_function_declaration; however, an expression_function_declaration
can complete a previous declaration.

3.2/5 A potentially static expression is defined in the same way as a static
expression except that

3.3/5   * a name denoting a formal parameter of an expression function is a
        potentially static expression; and

3.4/5   * each use of "static expression" in the definition of "static
        expression" is replaced with a corresponding use of "potentially
        static expression" in the definition of "potentially static
        expression".

3.5/5 The following language-defined representation aspect may be specified
for an expression function:

3.6/5 Static    The type of aspect Static is Boolean. When aspect Static is
                True for an expression function, the function is a static
                expression function. If directly specified, the
                aspect_definition shall be a static expression.

3.7/5           The Static value for an inherited function is True if some
                corresponding primitive function of the parent or progenitor
                type is a static expression function; otherwise, if not
                directly specified, the aspect is False.

3.8/5 A static expression function is a static function; see 4.9.


                               Legality Rules

4/3 If an expression_function_declaration is a completion, it shall be the
completion of a subprogram_declaration or generic_subprogram_declaration. The
profile of an expression_function_declaration that completes a declaration
shall conform fully to that of the declaration.

5/4 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 or aggregate of the expression_-
function_declaration, shall not be statically deeper than that of the master
that elaborated the expression_function_declaration.

5.1/5 Aspect Static shall be specified to have the value True only if the
associated expression_function_declaration:

5.2/5   * is not a completion;

5.3/5   * has an expression that is a potentially static expression;

5.4/5   * contains no calls to itself;

5.5/5   * each parameter (if any) is of mode in and is of a static subtype;

5.6/5   * has a result subtype that is a static subtype;

5.7/5   * has no applicable precondition or postcondition expression; and

5.8/5   * for result type R, if the function is a boundary entity for type R
        (see 7.3.2), no type invariant applies to type R; if R has a component
        type C, a similar rule applies to C.

Paragraph 6 was deleted.


                              Dynamic Semantics

7/4 The execution of an expression function is invoked by a subprogram call.
For the execution of a subprogram call on an expression function, the
execution of the subprogram_body executes an implicit function body containing
only a simple_return_statement whose expression is the return expression of
the expression function.

8/3 The elaboration of an expression_function_declaration has no other effect
than to establish that the expression function can be called without failing
the Elaboration_Check.


                                  Examples

9/3     function Is_Origin (P : in Point) return Boolean is -- see 3.9
           (P.X = 0.0 and P.Y = 0.0);

