dwww Home | Show directory contents | Find package


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

1.a         To be honest: A function call is an expression, but more
            specifically it is a name.

1.b/2       Glossary entry: A subprogram is a section of a program that can be
            executed in various contexts. It is invoked by a subprogram call
            that may qualify the effect of the subprogram through the passing
            of parameters. There are two forms of subprograms: functions,
            which return values, and procedures, which do not.

1.c/2       Glossary entry: A function is a form of subprogram that returns a
            result and can be called as part of an expression.

1.d/2       Glossary entry: A procedure is a form of subprogram that does not
            return a result and can only be called by a statement.

2/3 {AI05-0299-1} 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.

2.a         Ramification: Note that "callable entity" includes predefined
            operators, enumeration literals, and abstract subprograms. "
            Call" includes calls of these things. They do not have callable
            constructs, since they don't have completions.


6.1 Subprogram Declarations


1   [A subprogram_declaration declares a procedure or function.]


                                   Syntax

2/3     {AI95-00218-03} {AI05-0183-1} subprogram_declaration ::= 
            [overriding_indicator]
            subprogram_specification
                [aspect_specification];

3/2     This paragraph was deleted.{AI95-00348-01}

4/2     {AI95-00348-01} subprogram_specification ::= 
            procedure_specification
          | function_specification

4.1/2   {AI95-00348-01} procedure_specification ::= 
        procedure defining_program_unit_name parameter_profile

4.2/2   {AI95-00348-01} function_specification ::= 
        function defining_designator parameter_and_result_profile

5       designator ::= [parent_unit_name . ]identifier | operator_symbol

6       defining_designator ::= defining_program_unit_name
         | defining_operator_symbol

7       defining_program_unit_name ::= [parent_unit_name
         . ]defining_identifier

8       [The optional parent_unit_name is only allowed for library units (see
        10.1.1).]

9       operator_symbol ::= string_literal

10/3    {AI95-00395-01} {AI05-0299-1} 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.

10.a/3      Reason: {AI95-00395-01} {AI05-0090-1} The "sequence of
            characters" of the string literal of the operator is a technical term (see
            2.6), and does not include the surrounding quote characters. As
            defined in 2.2, lexical elements are "formed" from a sequence of
            characters. Spaces are not allowed, and upper and lower case is
            not significant.

11      defining_operator_symbol ::= operator_symbol

12      parameter_profile ::= [formal_part]

13/2    {AI95-00231-01} {AI95-00318-02} parameter_and_result_profile ::= 
            [formal_part] return [null_exclusion] subtype_mark
          | [formal_part] return access_definition

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

15/3    {AI95-00231-01} {AI05-0142-4} 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 {AI05-0143-1} 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.

18.a/3      This paragraph was deleted.{AI05-0143-1}

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

20/3 {AI95-00348-01} {AI05-0177-1} {AI05-0229-1} 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).]

20.a/3      Ramification: {AI95-00348-01} {AI05-0177-1} Abstract subprograms ,
            null procedures, and expression functions are not declared by
            subprogram_declarations, and so do not require completion
            (although the latter two can be completions). Protected
            subprograms are declared by subprogram_declarations, and so
            require completion. Note that an abstract subprogram is a
            subprogram, a null procedure is a subprogram, an expression
            function is a subprogram, and a protected subprogram is a
            subprogram, but a generic subprogram is not a subprogram.

20.b/3      Proof: {AI05-0229-1} When the Import aspect is True for any
            entity, no completion is allowed (see B.1).

21  A name that denotes a formal parameter is not allowed within the
formal_part in which it is declared, nor within the formal_part of a
corresponding body or accept_statement.

21.a        Ramification: By contrast, generic_formal_parameter_declarations
            are visible to subsequent declarations in the same
            generic_formal_part.


                              Static Semantics

22  The profile of (a view of) a callable entity is either a
parameter_profile or parameter_and_result_profile[; it embodies information
about the interface to that entity - for example, the profile includes
information about parameters passed to the callable entity. All callable
entities have a profile - enumeration literals, other subprograms, and
entries. An access-to-subprogram type has a designated profile.] Associated
with a profile is a calling convention. A subprogram_declaration declares a
procedure or a function, as indicated by the initial reserved word, with name
and profile as given by its specification.

23/2 {AI95-00231-01} {AI95-00318-02} 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 {AI05-0142-4} An explicitly aliased parameter is a formal parameter
whose parameter_specification includes the reserved word aliased.

24/2 {AI95-00231-01} {AI95-00254-01} {AI95-00318-02} 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.]

24.a/2      Discussion: {AI95-00318-02} Access result types have normal
            accessibility and thus don't have any special properties worth
            noting here.

25  The subtypes of a profile are:

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

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

27.1/3   * {AI95-00254-01} {AI05-0164-1} For any access parameters of an
        access-to-subprogram type, the subtypes of the designated profile of
        the parameter type.

28/2   * {AI95-00231-01} {AI95-00318-02} For any non-access result, the
        nominal subtype of the function result.

28.1/2   * {AI95-00318-02} For any access result type of an access-to-object
        type, the designated subtype of the result type.

28.2/3   * {AI95-00318-02} {AI05-0164-1} 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 {AI95-00348-01} {AI05-0177-1} [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 {AI95-00218-03} [An overriding_indicator is used to indicate whether
overriding is intended. See 8.3.1, "Overriding Indicators".]


                              Dynamic Semantics

31/2 {AI95-00348-01} 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    {AI12-0056-1}
        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);


                            Extensions to Ada 83

42.a        The syntax for abstract_subprogram_declaration is added. The
            syntax for parameter_specification is revised to allow for access
            parameters (see 3.10)

42.b/3      {AI05-0299-1} Program units that are library units may have a
            parent_unit_name to indicate the parent of a child (see 10.1.1).


                         Wording Changes from Ada 83

42.c        We have incorporated the rules from RM83-6.5, "Function
            Subprograms" here and in 6.3, "Subprogram Bodies"

42.d        We have incorporated the definitions of RM83-6.6, "Parameter and
            Result Type Profile - Overloading of Subprograms" here.

42.e        The syntax rule for defining_operator_symbol is new. It is used
            for the defining occurrence of an operator_symbol, analogously to
            defining_identifier. Usage occurrences use the direct_name or
            selector_name syntactic categories. The syntax rules for
            defining_designator and defining_program_unit_name are new.


                            Extensions to Ada 95

42.f/2      {AI95-00218-03} Subprograms now allow overriding_indicators for
            better error checking of overriding.

42.g/2      {AI95-00231-01} An optional null_exclusion can be used in a formal
            parameter declaration. Similarly, an optional null_exclusion can
            be used in a function result.

42.h/2      {AI95-00318-02} The return type of a function can be an anonymous
            access type.


                         Wording Changes from Ada 95

42.i/2      {AI95-00254-01} A description of the purpose of anonymous
            access-to-subprogram parameters and the definition of the profile
            of subprograms containing them was added.

42.j/2      {AI95-00348-01} Split the production for
            subprogram_specification in order to make the declaration of null
            procedures (see 6.7) easier.

42.k/2      {AI95-00348-01} Moved the Syntax and Dynamic Semantics for
            abstract_subprogram_declaration to 3.9.3, so that the syntax and
            semantics are together. This also keeps abstract and null
            subprograms similar.

42.l/2      {AI95-00395-01} Revised to allow other_format characters in
            operator_symbols in the same way as the underlying constructs.


                           Extensions to Ada 2005

42.m/3      {AI05-0142-4} Parameters can now be explicitly aliased, allowing
            parts of function results to designate parameters and forcing
            by-reference parameter passing.

42.n/3      {AI05-0143-1} The parameters of a function can now have any mode.

42.o/3      {AI05-0183-1} An optional aspect_specification can be used in a
            subprogram_declaration. This is described in 13.1.1.


                        Wording Changes from Ada 2005

42.p/3      {AI05-0177-1} Added expression functions (see 6.8) to the wording.


6.1.1 Preconditions and Postconditions


1/4 {AI05-0145-2} {AI05-0247-1} {AI12-0045-1} For a noninstance subprogram, a
generic subprogram, or an entry, the following language-defined aspects may be
specified with an aspect_specification (see 13.1.1):

1.a/4       Ramification: {AI12-0045-1} "Noninstance subprogram" excludes a
            subprogram that is an instance of a generic subprogram. In that
            case, the aspects should be specified on the generic subprogram.
            If preconditions or postconditions need to be added to an instance
            of a generic subprogram, it can be accomplished by creating a
            separate subprogram specification and then completing that
            specification with a renames-as-body of the instance.

2/3 Pre         This aspect specifies a specific precondition for a callable
                entity; 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.

2.a/3       To be honest: In this and the following rules, we are talking
            about the enumeration literal True declared in package Standard
            (see A.1), and not some other value or identifier True. That
            matters as some rules depend on full conformance of these
            expressions, which depends on the specific declarations involved.

2.b/3       Aspect Description for Pre: Precondition; a condition that must
            hold true before a call.

3/3 {AI05-0254-1} {AI05-0262-1} 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.

3.a/3       Ramification: {AI05-0254-1} If other class-wide preconditions
            apply to the entity and no class-wide precondition is specified,
            no class-wide precondition is defined for the entity; of course,
            the class-wide preconditions (of ancestors) that apply are still
            going to be checked. We need subprograms that don't have ancestors
            and don't specify a class-wide precondition to have a class-wide
            precondition of True, so that adding such a precondition to a
            descendant has no effect (necessary as a dispatching call through
            the root routine would not check any precondition).

3.b/3       Aspect Description for Pre'Class: Precondition inherited on type
            derivation.

4/3 Post        This aspect specifies a specific postcondition for a callable
                entity; 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.

4.a/3       Aspect Description for Post: Postcondition; a condition that must
            hold true after a call.

5/3 {AI05-0262-1} 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.

5.a/3       Aspect Description for Post'Class: Postcondition inherited on type
            derivation.


                            Name Resolution Rules

6/3 {AI05-0145-2} The expected type for a precondition or postcondition
expression is any boolean type.

7/4 {AI05-0145-2} {AI05-0262-1} {AI12-0113-1} {AI12-0159-1} 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) 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.]

7.a/4       Reason: {AI12-0159-1} This ensures that the expression is
            well-defined for any primitive subprogram of a type descended from
            T.

8/3 {AI05-0145-2} {AI05-0264-1} 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 {AI05-0145-2} {AI05-0230-1} 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.]

9.a/3       Discussion: {AI05-0183-1} Pre'Class and Post'Class can only be
            specified on primitive routines of tagged types, by a blanket rule
            found in 13.1.1.

10/3 {AI05-0247-1} {AI05-0254-1} 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 {AI05-0247-1} {AI05-0254-1} 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.

16.a/3      Discussion: We use the term "requires overriding" here so that
            this rule is taken into account when calculating visibility in
            8.3; otherwise we would have a mess when this routine is
            overridden.

16.b/3      Reason: Such an inherited subprogram would necessarily violate the
            Liskov Substitutability Principle (LSP) if called via a
            dispatching call from an ancestor other than the one that provides
            the called body. In such a case, the class-wide precondition of
            the actual body is stronger than the class-wide precondition of
            the ancestor. If we did not enforce that precondition for the
            body, the body could be called when the precondition it knows
            about is False - such "counterfeiting" of preconditions has to be
            avoided. But enforcing the precondition violates LSP. We do not
            want the language to be implicitly creating bodies that violate
            LSP; the programmer can still write an explicit body that calls
            the appropriate parent subprogram. In that case, the violation of
            LSP is explicitly in the code and obvious to code reviewers (both
            human and automated).

16.c/3      We have to say that the subprogram is abstract for an abstract
            type in this case, so that the next concrete type has to override
            it for the reasons above. Otherwise, inserting an extra level of
            abstract types would eliminate the requirement to override (as
            there is only one declared operation for the concrete type), and
            that would be bad for the reasons given above.

16.d/3      Ramification: This requires the set of class-wide preconditions
            that apply to the interface routine to be strictly stronger than
            those that apply to the concrete routine. Since full conformance
            requires each name to denote the same declaration, it is unlikely
            that independently declared preconditions would conform. This rule
            does allow "diamond inheritance" of preconditions, and of course
            no preconditions at all match.

16.e/3      We considered adopting a rule that would allow examples where the
            expressions would conform after all inheritance has been applied,
            but this is complex and is not likely to be common in practice.
            Since the penalty here is just that an explicit overriding is
            required, the complexity is too much.

17/3 {AI05-0247-1} 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.a/3      Reason: Such an overriding subprogram would violate LSP, as the
            precondition of S1 would usually be different (and thus stronger)
            than the one known to a dispatching call through an ancestor
            routine of S2. This is always OK if the preconditions match, so we
            always allow that.

17.b/3      Ramification: This only applies to primitives of tagged types;
            other routines cannot have class-wide preconditions.

17.1/4 {AI12-0131-1} 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.c/4      Reason: Any such Pre'Class will have no effect, as it will be ored
            with True. As such, it is highly misleading for readers,
            especially for those who are determining the assumptions that can
            be made in the body of the primitive subprogram. Note that in this
            case there is nothing explicit that might indicate that the
            class-wide precondition is ineffective. This rule does not prevent
            explicitly writing an ineffective class-wide precondition (for
            instance, if the parent subprogram has explicitly specified a
            precondition of True).

17.2/4 {AI12-0131-1} 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/4 {AI05-0145-2} {AI12-0113-1} {AI12-0131-1} 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. The
corresponding expression is constructed from the associated expression as
follows:

18.a/4      Ramification: A Pre'Class defaults to True only if no class-wide
            preconditions are inherited for the subprogram. The same is true
            for Post'Class.

18.b/4      Reason: We have to inherit precondition expressions that default
            to True, so that later overridings don't strengthen the
            precondition (a violation of LSP). We do the same for
            postconditions for consistency.

18.1/4   * {AI12-0113-1} 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.c/4      Reason: We have to define the corresponding expression this way as
            overriding routines are only required to be subtype conformant; in
            particular, the parameter names can be different. So we have to
            talk about corresponding parameters without mentioning any names.

18.2/4 {AI12-0113-1} 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.

18.d/4      Ramification: This can happen, for instance, if one of the
            subprograms called in the corresponding expression is abstract. We
            made the rule general so that we don't have to worry about exactly
            which cases can cause this to happen, both now and in the future.

18.e/4      Reason: We allow illegal corresponding expressions on abstract
            subprograms as they could never be evaluated, and we need to allow
            such expressions to contain calls to abstract subprograms.

19/3 {AI05-0145-2} {AI05-0262-1} {AI05-0290-1} 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 or entry, then the respective precondition or
postcondition expressions are considered enabled.

19.a/3      Ramification: {AI05-0290-1} If a class-wide precondition or
            postcondition expression is enabled, it remains enabled when
            inherited by an overriding subprogram, even if the policy in
            effect is Ignore for the inheriting subprogram.

20/3 {AI05-0273-1} An expression is potentially unevaluated if it occurs
within:

21/3   * any part of an if_expression other than the first condition;

22/3   * a dependent_expression of a case_expression;

22.1/4   * {AI12-0032-1} a predicate of a quantified_expression;

23/3   * the right operand of a short-circuit control form; or

24/3   * a membership_choice other than the first of a membership operation.

25/3 {AI05-0145-2} For a prefix X that denotes an object of a nonlimited type,
the following attribute is defined:

26/4 X'Old      {AI05-0145-2} {AI05-0262-1} {AI05-0273-1} {AI12-0032-1} Each
                X'Old in a postcondition expression that is enabled denotes a
                constant that is implicitly declared at the beginning of the
                subprogram body, entry body, or accept statement.

26.1/4          {AI12-0032-1} {AI12-0159-1} 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.a/4      Ramification: This means that the underlying tag associated with
            X'Old is that of X and not that of the nominal type of X.

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/4         {AI12-0032-1} The nominal subtype of X'Old is as implied by
                the above definitions. The expected type of the prefix of an
                Old attribute is that of the attribute. Similarly, if an Old
                attribute shall resolve to be of some type, then the prefix of
                the attribute shall resolve to be of that type.

27/3            {AI05-0145-2} {AI05-0262-1} {AI05-0273-1} 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 that is potentially unevaluated
                shall statically denote an entity.

27.a/3      Discussion: The prefix X can be any nonlimited object that obeys
            the syntax for prefix other than the few exceptions given above
            (discussed below). Useful cases are: the name of a formal
            parameter of mode [in] out, the name of a global variable updated
            by the subprogram, a function call passing those as parameters, a
            subcomponent of those things, etc.

27.b/3      A qualified expression can be used to make an arbitrary expression
            into a valid prefix, so T'(X + Y)'Old is legal, even though (X +
            Y)'Old is not. The value being saved here is the sum of X and Y (a
            function result is an object). Of course, in this case "+"(X,
            Y)'Old is also legal, but the qualified expression is arguably
            more readable.

27.c/3      Note that F(X)'Old and F(X'Old) are not necessarily equal. The
            former calls F(X) and saves that value for later use during the
            postcondition. The latter saves the value of X, and during the
            postcondition, passes that saved value to F. In most cases, the
            former is what one wants (but it is not always legal, see below).

27.d/4      {AI12-0032-1} If X has controlled parts, adjustment and
            finalization are implied by the implicit constant declaration.
            Similarly, the implicit constant declaration defines the
            accessibility level of X'Old.

27.e/3      If postconditions are disabled, we want the compiler to avoid any
            overhead associated with saving 'Old values.

27.f/3      'Old makes no sense for limited types, because its implementation
            involves copying. It might make semantic sense to allow
            build-in-place, but it's not worth the trouble.

27.g/3      Reason: {AI05-0273-1} Since the prefix is evaluated
            unconditionally when the subprogram is called, we cannot allow it
            to include values that do not exist at that time (like 'Result and
            loop parameters of quantified_expressions). We also do not allow
            it to include 'Old references, as those would be redundant (the
            entire prefix is evaluated when the subprogram is called), and
            allowing them would require some sort of order to the implicit
            constant declarations (because in A(I'Old)'Old, we surely would
            want the value of I'Old evaluated before the A(I'Old) is
            evaluated).

27.h/3      {AI05-0273-1} In addition, we only allow simple names as the
            prefix of the Old attribute if the attribute_reference might not
            be evaluated when the postcondition expression is evaluated. This
            is necessary because the Old prefixes have to be unconditionally
            evaluated when the subprogram is called; the compiler cannot in
            general know whether they will be needed in the postcondition
            expression. To see the problem, consider:

27.i/3          Table : array (1..10) of Integer := ...
                procedure Bar (I : in out Natural)
                   with Post => I > 0 and then Table(I)'Old = 1; -- Illegal

27.j/3      In this example, the compiler cannot know the value of I when the
            subprogram returns (since the subprogram execution can change it),
            and thus it does not know whether Table(I)'Old will be needed
            then. Thus it has to always create an implicit constant and
            evaluate Table(I) when Bar is called (because not having the value
            when it is needed is not acceptable). But if I = 0 when the
            subprogram is called, that evaluation will raise Constraint_Error,
            and that will happen even if I is unchanged by the subprogram and
            the value of Table(I)'Old is not ultimately needed. It's easy to
            see how a similar problem could occur for a dereference of an
            access type. This would be mystifying (since the point of the
            short circuit is to eliminate this possibility, but it cannot do
            so). Therefore, we require the prefix of any Old attribute in such
            a context to statically denote an object, which eliminates
            anything that could change at during execution.

27.k/3      It is easy to work around most errors that occur because of this
            rule. Just move the 'Old to the outer object, before any indexing,
            dereferences, or components. (That does not work for function
            calls, however, nor does it work for array indexing if the index
            can change during the execution of the subprogram.)

27.l/4      Ramification: {AI12-0032-1} An accept statement for a task entry
            with enabled postconditions such as

27.m/4          accept E do
                   statements
                exception
                   handlers
                end;

27.n/4      behaves (at runtime) as follows:

27.o/4          accept E do
                   declare
                      declarations, if any, of 'Old constants
                   begin
                      begin
                         statements
                      exception
                         handlers
                      end;
                      postcondition checks
                   end;
                end;

27.p/4      {AI12-0032-1} Preconditions are checked by the caller before the
            rendezvous begins. Postcondition expressions might, of course,
            reference 'Old constants.

27.q/4      {AI12-0032-1} In the case of a protected operation with enabled
            postconditions, 'Old constant declarations (if any) are elaborated
            after the start of the protected action. Postcondition checks
            (which might reference these constants) are performed before the
            end of the protected action as described below.

28/3 {AI05-0145-2} For a prefix F that denotes a function declaration, the
following attribute is defined:

29/3 F'Result   {AI05-0145-2} {AI05-0262-1} Within a postcondition expression
                for function F, denotes the result object of the function. The
                type of this attribute is that of the function result except
                within a Post'Class postcondition expression for a function
                with a controlling result or with a controlling access result.
                For a controlling result, the type of the attribute is
                T'Class, where T is the function result type. For a
                controlling access result, the type of the attribute is an
                anonymous access type whose designated type is T'Class, where
                T is the designated type of the function result type.

30/3            {AI05-0262-1} Use of this attribute is allowed only within a
                postcondition expression for F.


                              Dynamic Semantics

31/3 {AI05-0145-2} {AI05-0247-1} {AI05-0290-1} 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.

33.a/3      Ramification: The class-wide precondition expressions of the
            entity itself as well as those of any parent or progenitor
            operations are evaluated, as these expressions apply to the
            corresponding operations of all descendants.

33.b/3      Class-wide precondition checks are performed for all appropriate
            calls, but only enabled precondition expressions are evaluated.
            Thus, the check would be trivial if no precondition expressions
            are enabled.

34/3 {AI05-0145-2} {AI05-0247-1} {AI05-0254-1} {AI05-0269-1} 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. It is not specified whether in a call on a protected
operation, the checks are performed before or after starting the protected
action. For an entry call, the checks are performed prior to checking whether
the entry is open.

34.a/3      Reason: We need to explicitly allow short-circuiting of the
            evaluation of the class-wide precondition check if any expression
            fails, as it consists of multiple expressions; we don't need a
            similar permission for the specific precondition check as it
            consists only of a single expression. Nothing is evaluated for the
            call after a check fails, as the failed check propagates an
            exception.

35/3 {AI05-0145-2} {AI05-0247-1} {AI05-0254-1} {AI05-0262-1} {AI05-0290-1}
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.a/3      Ramification: The class-wide postcondition expressions of the
            entity itself as well as those of any parent or progenitor
            operations are evaluated, as these apply to all descendants; in
            contrast, only the specific postcondition of the entity applies.
            Postconditions can always be evaluated inside the invoked body.

35.1/4 {AI12-0032-1} 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.

35.a.1/4    Reason: {AI12-0032-1} If a postcondition references the
            implicitly-declared constant associated with an Old attribute, the
            postcondition must be evaluated before the constant is finalized.
            One way to think of this is to imagine declaring a controlled
            object between any implicit "'Old" constant declarations and any
            explicit declarations, then performing postcondition checks during
            the finalization of this object.

36/3 {AI05-0145-2} {AI05-0262-1} 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 {AI05-0145-2} {AI05-0247-1} {AI05-0254-1} {AI05-0262-1} {AI12-0113-1}
{AI12-0159-1} 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.]

37.a/3      Ramification: This applies to access-to-subprogram calls,
            dispatching calls, and to statically bound calls. We need this
            rule to cover statically bound calls as well, as specific pre- and
            postconditions are not inherited, but the subprogram might be.

37.b/3      For concrete subprograms, we require the original specific
            postcondition to be evaluated as well as the inherited class-wide
            postconditions in order that the semantics of an explicitly
            defined wrapper that does nothing but call the original subprogram
            is the same as that of an inherited subprogram.

37.c/3      Note that this rule does not apply to class-wide preconditions;
            they have their own rules mentioned below.

38/4 {AI05-0145-2} {AI05-0247-1} {AI05-0254-1} {AI12-0113-1} {AI12-0159-1} 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.a/3      Ramification: For a dispatching call, we are talking about the
            Pre'Class(es) that apply to the subprogram that the dispatching
            call is resolving to, not the Pre'Class(es) for the subprogram
            that is ultimately dispatched to. The class-wide precondition of
            the resolved call is necessarily the same or stronger than that of
            the invoked call. For a statically bound call, these are the same;
            for an access-to-subprogram, (which has no class-wide
            preconditions of its own), we check the class-wide preconditions
            of the invoked routine.

38.b/3      Implementation Note: These rules imply that logically, class-wide
            preconditions of routines must be checked at the point of call
            (other than for access-to-subprogram calls, which must be checked
            in the body, probably using a wrapper). Specific preconditions
            that might be called with a dispatching call or via an
            access-to-subprogram value must be checked inside of the
            subprogram body. In contrast, the postcondition checks always need
            to be checked inside the body of the routine. Of course, an
            implementation can evaluate all of these at the point of call for
            statically bound calls if the implementation uses wrappers for
            dispatching bodies and for 'Access values.

38.c/3      There is no requirement for an implementation to generate special
            code for routines that are imported from outside of the Ada
            program. That's because there is a requirement on the programmer
            that the use of interfacing aspects do not violate Ada semantics
            (see B.1). That includes making pre- and postcondition checks. For
            instance, if the implementation expects routines to make their own
            postcondition checks in the body before returning, C code can be
            assumed to do this (even though that is highly unlikely). That's
            even though the formal definition of those checks is that they are
            evaluated at the call site. Note that pre- and postconditions can
            be very useful for verification tools (even if they aren't
            checked), because they tell the tool about the expectations on the
            foreign code that it most likely cannot analyze.

39/3 {AI05-0145-2} {AI05-0247-1} {AI05-0254-1} For a call via an
access-to-subprogram value, all precondition and postcondition checks
performed are determined by the subprogram or entry denoted by the prefix of
the Access attribute reference that produced the value.

        NOTES

40/3    5  {AI05-0145-2} {AI05-0262-1} 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.


                           Extensions to Ada 2005

40.a/3      {AI05-0145-2} {AI05-0230-1} {AI05-0247-1} {AI05-0254-1}
            {AI05-0262-1} {AI05-0273-1} {AI05-0274-1} Pre and Post aspects are
            new.


                        Inconsistencies With Ada 2012

40.b/4      {AI12-0032-1} Corrigendum: The Old attribute is defined more
            carefully. This changes the nominal subtype and place of
            declaration of the attribute compared to the published Ada 2012
            Standard. In extreme cases, this could change the runtime behavior
            of the attribute (for instance, the tag might be different). The
            changes are most likely going to prevent bugs by being more
            intuitive, but it is possible that a program that previously
            worked might fail.

40.c/4      {AI12-0113-1} {AI12-0159-1} Corrigendum: Eliminated unintentional
            redispatching from class-wide preconditions and postconditions.
            This means that a different body might be evaluated for a
            statically bound call to a routine that has a class-wide
            precondition or postcondition. The change means that the behavior
            of Pre and Pre'Class will be the same for a particular subprogram,
            and that the known behavior of the operations can be assumed
            within the body of that subprogram for Pre'Class. We expect that
            this change will primarily fix bugs, as it will make Pre'Class and
            Post'Class work more like expected. In the case where
            redispatching is desired, an explicit conversion to a class-wide
            type can be used.


                       Incompatibilities With Ada 2012

40.d/4      {AI12-0045-1} Corrigendum: Precondition and postcondition aspects
            cannot be specified on instances of generic subprograms (they
            should be specified on the generic subprogram instead). This was
            (unintentionally) allowed by the Ada 2012 standard. These are not
            be allowed on instances as there is no corresponding way to add
            preconditions and postconditions to subprograms declared within
            the instance of a generic package. Therefore, allowing
            specification on a subprogram instance could present a maintenance
            problem in the future if the entity needs to be converted to a
            generic package (a common conversion).

40.e/4      {AI12-0131-1} Corrigendum: Pre'Class is no longer allowed to be
            specified for an overriding primitive subprogram unless there are
            also inherited class-wide precondittions. This incompatibility
            prevents cases where the explicit Pre'Class is counterfeited by an
            implicit class-wide precondition of True. This rule should catch
            more bugs than it creates; the programmer should have written Pre
            rather than Pre'Class in this case (or written Pre'Class on the
            original subprogram, not an overriding). Note that this
            incompatibility eliminates what otherwise would be an
            inconsistency with original Ada 2012, where precondition checks
            that would have previously been made for a statically bound call
            would no longer be made. That dynamic change was necessary to
            eliminate cases where the evaluated class-wide precondition on a
            dispatching call would have been weaker than the class-wide
            precondition of a statically bound call. (The original Ada 2012
            violated the LSP semantics that class-wide preconditions were
            intended to model.


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 {AI05-0142-4} {AI05-0262-1} 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   * {AI05-0096-1} an explicitly limited record type;

7.a/3       This paragraph was deleted.{AI05-0096-1}

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/4 {AI05-0142-4} {AI05-0188-1} {AI12-0027-1} 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
parenthesized expression, qualified_expression, or view conversion, this
object is the one associated with the operand. 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. For a
conditional_expression, this object is the one associated with the evaluated
dependent_expression.

10.a        Ramification: By-reference parameter passing makes sense only if
            there is an object to reference; hence, we define such an object
            for each case.

10.b        Since tagged types are by-reference types, this implies that every
            value of a tagged type has an associated object. This simplifies
            things, because we can define the tag to be a property of the
            object, and not of the value of the object, which makes it clearer
            that object tags never change.

10.c        We considered simplifying things even more by making every value
            (and therefore every expression) have an associated object. After
            all, there is little semantic difference between a constant object
            and a value. However, this would cause problems for untagged
            types. In particular, we would have to do a constraint check on
            every read of a type conversion (or a renaming thereof) in certain
            cases.

10.d/2      {AI95-00318-02} We do not want this definition to depend on the
            view of the type; privateness is essentially ignored for this
            definition. Otherwise, things would be confusing (does the rule
            apply at the call site, at the site of the declaration of the
            subprogram, at the site of the return statement?), and requiring
            different calls to use different mechanisms would be an
            implementation burden.

10.e        C.6, "Shared Variable Control" says that a composite type with an
            atomic or volatile subcomponent is a by-reference type, among
            other things.

10.f        Every value of a limited by-reference type is the value of one and
            only one limited object. The associated object of a value of a
            limited by-reference type is the object whose value it represents.
            Two values of a limited by-reference type are the same if and only
            if they represent the value of the same object.

10.g        We say "by-reference" above because these statements are not
            always true for limited private types whose underlying type is
            nonlimited (unfortunately).

11/3 {AI05-0240-1} For other parameters, it is unspecified whether the
parameter is passed by copy or by reference.

11.a/3      Discussion: {AI05-0005-1} There is no need to incorporate the
            discussion of AI83-00178, which requires pass-by-copy for certain
            kinds of actual parameters, while allowing pass-by-reference for
            others. This is because we explicitly indicate that a function
            creates an anonymous constant object for its result (see 6.5). We
            also provide a special dispensation for instances of
            Unchecked_Conversion to return by reference (see 13.9).


                          Bounded (Run-Time) Errors

12/3 {AI05-0240-1} 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.

12.a        Discussion: For example, if we call "P(X => Global_Variable, Y =>
            Global_Variable)", then within P, the names "X", "Y", and "
            Global_Variable" are all distinct access paths. If
            Global_Variable's type is neither pass-by-copy nor
            pass-by-reference, then it is a bounded error to assign to
            Global_Variable and then read X or Y, since the language does not
            specify whether the old or the new value would be read. On the
            other hand, if Global_Variable's type is pass-by-copy, then the
            old value would always be read, and there is no error. Similarly,
            if Global_Variable's type is defined by the language to be
            pass-by-reference, then the new value would always be read, and
            again there is no error.

12.b        Reason: We are saying assign here, not update, because updating
            any subcomponent is considered to update the enclosing object.

12.c        The "still exists" part is so that a read after the subprogram
            returns is OK.

12.d        If the parameter is of a by-copy type, then there is no issue here
            - the formal is not a view of the actual. If the parameter is of a
            by-reference type, then the programmer may depend on updates
            through one access path being visible through some other access
            path, just as if the parameter were of an access type.

12.e        Implementation Note: The implementation can keep a copy in a
            register of a parameter whose parameter-passing mechanism is not
            specified. If a different access path is used to update the object
            (creating a bounded error situation), then the implementation can
            still use the value of the register, even though the in-memory
            version of the object has been changed. However, to keep the error
            properly bounded, if the implementation chooses to read the
            in-memory version, it has to be consistent -- it cannot then
            assume that something it has proven about the register is true of
            the memory location. For example, suppose the formal parameter is
            L, the value of L(6) is now in a register, and L(6) is used in an
            indexed_component as in "A(L(6)) := 99;", where A has bounds 1..3.
            If the implementation can prove that the value for L(6) in the
            register is in the range 1..3, then it need not perform the
            constraint check if it uses the register value. However, if the
            memory value of L(6) has been changed to 4, and the implementation
            uses that memory value, then it had better not alter memory
            outside of A.

12.f        Note that the rule allows the implementation to pass a parameter
            by reference and then keep just part of it in a register, or,
            equivalently, to pass part of the parameter by reference and
            another part by copy.

12.g        Reason: We do not want to go so far as to say that the mere
            presence of aliasing is wrong. We wish to be able to write the
            following sorts of things in standard Ada:

12.h            procedure Move ( Source  : in  String;
                                 Target  : out String;
                                 Drop    : in  Truncation := Error;
                                 Justify : in  Alignment  := Left;
                                 Pad     : in  Character  := Space);
                -- Copies elements from Source to Target (safely if they overlap)

12.i        This is from the standard string handling package. It would be
            embarrassing if this couldn't be written in Ada!

12.j        The "then" before "read" in the rule implies that the
            implementation can move a read to an earlier place in the code,
            but not to a later place after a potentially aliased assignment.
            Thus, if the subprogram reads one of its parameters into a local
            variable, and then updates another potentially aliased one, the
            local copy is safe - it is known to have the old value. For
            example, the above-mentioned Move subprogram can be implemented by
            copying Source into a local variable before assigning into Target.

12.k        For an assignment_statement assigning one array parameter to
            another, the implementation has to check which direction to copy
            at run time, in general, in case the actual parameters are
            overlapping slices. For example:

12.l            procedure Copy(X : in out String; Y: String) is
                begin
                    X := Y;
                end Copy;

12.m        It would be wrong for the compiler to assume that X and Y do not
            overlap (unless, of course, it can prove otherwise).

        NOTES

13/4    6  {AI12-0056-1} The mode of a formal parameter describes the
        direction of information transfer to or from the subprogram_body (see
        6.1).

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

15/4    8  {AI12-0056-1} A formal parameter of mode out might be uninitialized
        at the start of the subprogram_body (see 6.4.1).


                            Extensions to Ada 83

15.a        The value of an out parameter may be read. An out parameter is
            treated like a declared variable without an explicit initial
            expression.


                         Wording Changes from Ada 83

15.b        Discussion of copy-in for parts of out parameters is now covered
            in 6.4.1, "Parameter Associations".

15.c        The concept of a by-reference type is new to Ada 95.

15.d        We now cover in a general way in 3.7.2 the rule regarding
            erroneous execution when a discriminant is changed and one of the
            parameters depends on the discriminant.


                        Wording Changes from Ada 2005

15.e/3      {AI05-0096-1} Correction: Corrected so that limited derived types
            are by-reference only if their parent is.

15.f/3      {AI05-0142-4} Defined that explicitly aliased parameters (see
            6.1) are always passed by reference.


                        Wording Changes from Ada 2012

15.g/4      {AI05-0027-1} Corrigendum: Corrected so that value conversions
            that are copies are the "associated object" for parameter passing
            of by-reference types. This can only happen if the conversion is
            between unrelated non-limited types, and it is necessary just so
            the correct object is defined.


6.3 Subprogram Bodies


1   [A subprogram_body specifies the execution of a subprogram.]


                                   Syntax

2/3     {AI95-00218-03} {AI05-0183-1} 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.

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

11.f/2      {AI95-00218-03} Overriding_indicator is added to subprogram_body.


                           Extensions to Ada 2005

11.g/3      {AI05-0183-1} 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} {AI95-00117-01} [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   * {AI05-0229-1} 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      * {AI95-00252-01} a subprogram declared immediately within a
            protected_body;

10.1/4    * {AI95-00252-01} {AI95-00407-01} {AI12-0107-1} any prefixed view of
            a subprogram (see 4.1.3) without synchronization kind (see 9.5)
            By_Entry or By_Protected_Procedure.

10.a/2      Reason: The profile of a prefixed view is different than the "
            real" profile of the subprogram (it doesn't have the first parameter),
            so we don't want to be able to take 'Access of it, as that would
            require generating a wrapper of some sort.

10.b/4      {AI12-0107-1} 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      {AI05-0229-1} 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   * {AI12-0107-1} {AI12-0159-1} 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   * {AI12-0107-1} {AI12-0159-1} 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/3   * {AI95-00254-01} {AI95-00409-01} {AI05-0264-1} 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 subprogram that contains the parameter.

13.a/2      Ramification: The calling convention for other anonymous
            access-to-subprogram types is Ada.

13.2/1   * {8652/0011} {AI95-00117-01} [If not specified above as Intrinsic,
        the calling convention for any inherited or overriding dispatching
        operation of a tagged type is that of the corresponding subprogram of
        the parent type.] The default calling convention for a new dispatching
        operation of a tagged type is the convention of the type.

13.a.1/1    Reason: The first rule is officially stated in 3.9.2. The second
            is intended to make interfacing to foreign OOP languages easier,
            by making the default be that the type and operations all have the
            same convention.

14/3 {AI05-0229-1} 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: {AI05-0229-1} 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 {AI95-00409-01} 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: {AI95-00409-01} For anonymous access-to-object
            parameters, the designated types have to be the same for type
            conformance, not the access types, since in general each access
            parameter has its own anonymous access type, created when the
            subprogram is called. Of course, corresponding parameters have to
            be either both access parameters or both not access parameters.

15.b/2      {AI95-00409-01} Similarly, for anonymous access-to-subprogram
            parameters, the designated profiles of the types, not the types
            themselves, have to be conformant.

16/3 {AI95-00318-02} {AI95-00409-01} {AI05-0142-4} Two profiles are mode
conformant if:

16.1/3   * {AI05-0142-4} {AI05-0262-1} they are type conformant; and

16.2/3   * {AI05-0142-4} corresponding parameters have identical modes and
        both or neither are explicitly aliased parameters; and

16.3/3   * {AI05-0207-1} 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 {AI05-0239-1} 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 {AI05-0134-1} {AI05-0262-1} 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   * {AI05-0262-1} they have the same names; and

18.2/3   * {AI05-0046-1} 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   * {AI05-0134-1} for access-to-subprogram parameters, the designated
        profiles are fully conformant.

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: {AI05-0046-1} 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      {AI05-0134-1} 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    * 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   * {AI12-0050-1} corresponding defining_identifiers occurring within
        the two expressions are the same; and

21/4   * {AI12-0050-1} 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.a        Ramification: Note that it doesn't say "respectively" because a
            direct_name can correspond to a selector_name, and vice-versa, by
            the previous bullet. This rule allows the prefix of an expanded
            name to be removed, or replaced with a different prefix that
            denotes a renaming of the same entity. However, it does not allow
            a direct_name or selector_name to be replaced with one denoting a
            distinct renaming (except for direct_names and selector_names in
            prefixes of expanded names). Note that calls using operator
            notation are equivalent to calls using prefix notation.

21.b        Given the following declarations:

21.c            package A is
                    function F(X : Integer := 1) return Boolean;
                end A;

21.c.1/3        {AI05-0005-1} 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: {AI12-0050-1} 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} {AI95-00175-01} {AI05-0092-1} each
        attribute_designator in one is the same as the corresponding
        attribute_designator in the other; and

22    * each primary that is a literal in one has the same value as the
        corresponding literal in the other.

22.a        Ramification: The literals may be written differently.

22.b        Ramification: Note that the above definition makes full
            conformance a transitive relation.

23  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 {AI95-00345-01} {AI95-00397-01} The prefixed view profile of a
subprogram is the profile obtained by omitting the first parameter of that
subprogram. There is no prefixed view profile for a parameterless subprogram.
For the purposes of defining subtype and mode conformance, the convention of a
prefixed view profile is considered to match that of either an entry or a
protected operation.

24.c/2      Discussion: This definition is used to define how primitive
            subprograms of interfaces match operations in task and protected
            type definitions (see 9.1 and 9.4).

24.d/2      Reason: The weird rule about conventions is pretty much required
            for synchronized interfaces to make any sense. There will be
            wrappers all over the place for interfaces anyway. Of course, this
            doesn't imply that entries have the same convention as protected
            operations.


                         Implementation Permissions

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


                            Extensions to Ada 83

25.a        The rules for full conformance are relaxed - they are now based on
            the structure of constructs, rather than the sequence of lexical
            elements. This implies, for example, that "(X, Y: T)" conforms
            fully with "(X: T; Y: T)", and "(X: T)" conforms fully with "(X:
            in T)".


                         Wording Changes from Ada 95

25.b/2      {8652/0011} {AI95-00117-01} Corrigendum: Clarified that the
            default convention is Ada. Also clarified that the convention of a
            primitive operation of a tagged type is the same as that of the
            type.

25.c/2      {8652/0018} {AI95-00175-01} Corrigendum: Added wording to ensure
            that two attributes conform only if they have the same
            attribute_designator.

25.d/2      {AI95-00252-01} {AI95-00254-01} {AI95-00407-01} Defined the
            calling convention for anonymous access-to-subprogram types and
            for prefixed views of subprograms (see 4.1.3).

25.e/2      {AI95-00318-02} Defined the conformance of access result types
            (see 6.1).

25.f/2      {AI95-00345-01} {AI95-00397-01} Defined the prefixed view profile
            of subprograms for later use.

25.g/2      {AI95-00409-01} Defined the conformance of anonymous
            access-to-subprogram parameters.


                       Incompatibilities With Ada 2005

25.h/3      {AI05-0046-1} 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.

25.i/3      {AI05-0134-1} 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.

25.j/3      {AI05-0207-1} 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

25.k/3      {AI05-0142-4} Explicitly aliased parameters are included as part
            of mode conformance (since it affects the parameter passing
            mechanism).


                           Extensions to Ada 2012

25.l/4      {AI05-0107-1} {AI05-0159-1} 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

25.m/4      {AI05-0050-1} 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.


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 {AI05-0229-1} 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.{AI05-0229-1}

5.c/3   This paragraph was deleted.

5.d/3   This paragraph was deleted.

5.e/3       Ramification: {AI05-0229-1} 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 {AI05-0229-1} 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.{AI95-00309-01} {AI05-0229-1}


                            Extensions to Ada 83

7.b/3       This paragraph was deleted.{AI05-0229-1}


                            Extensions to Ada 95

7.c/3       This paragraph was deleted.{AI95-00309-01} {AI05-0229-1}


                           Extensions to Ada 2005

7.d/3       {AI05-0229-1} Aspect Inline is new; pragma Inline is now
            obsolescent.


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

3.a/3       To be honest: {AI05-0005-1} For the purpose of non-syntax rules,
            infix operator calls are considered function_calls. See 6.6.

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.

7.a         Ramification: This means that the formal parameter names used in
            describing predefined attributes are to aid presentation of their
            semantics, but are not intended for use in actual calls.


                            Name Resolution Rules

8/2 {AI95-00310-01} The name or prefix given in a procedure_call_statement
shall resolve to denote a callable entity that is a procedure, or an entry
renamed as (viewed as) a procedure. The name or prefix given in a
function_call shall resolve to denote a callable entity that is a function.
The name or prefix shall not resolve to denote an abstract subprogram unless
it is also a dispatching subprogram. [When there is an actual_parameter_-
part, the prefix can be an implicit_dereference of an access-to-subprogram
value.]

8.a.1/2     Discussion: {AI95-00310-01} This rule is talking about dispatching
            operations (which is a static concept) and not about dispatching
            calls (which is a dynamic concept).

8.a         Ramification: The function can be an operator, enumeration
            literal, attribute that is a function, etc.

9   A subprogram call shall contain at most one association for each formal
parameter. Each formal parameter without an association shall have a
default_expression (in the profile of the view denoted by the name or prefix
). [This rule is an overloading rule (see 8.6).]

9.a/3       Proof: {AI05-0240-1} All Name Resolution Rules are overloading
            rules, see 8.6.


                              Dynamic Semantics

10/2 {AI95-00345-01} For the execution of a subprogram call, the name or
prefix of the call is evaluated, and each parameter_association is evaluated
(see 6.4.1). If a default_expression is used, an implicit
parameter_association is assumed for this rule. These evaluations are done in
an arbitrary order. The subprogram_body is then executed, or a call on an
entry or protected subprogram is performed (see 3.9.2). Finally, if the
subprogram completes normally, then after it is left, any necessary assigning
back of formal to actual parameters occurs (see 6.4.1).

10.a        Discussion: The implicit association for a default is only for
            this run-time rule. At compile time, the visibility rules are
            applied to the default at the place where it occurs, not at the
            place of a call.

10.b        To be honest: If the subprogram is inherited, see 3.4, "
            Derived Types and Classes".

10.c        If the subprogram is protected, see 9.5.1, "
            Protected Subprograms and Protected Actions".

10.d        If the subprogram is really a renaming of an entry, see 9.5.3, 
            "Entry Calls".

10.d.1/2    {AI95-00345-01} If the subprogram is implemented by an entry or
            protected subprogram, it will be treated as a dispatching call to
            the corresponding entry (see 9.5.3, "Entry Calls") or protected
            subprogram (see 9.5.1, "
            Protected Subprograms and Protected Actions").

10.e/2      {AI95-00348-01} Normally, the subprogram_body that is executed by
            the above rule is the one for the subprogram being called. For an
            enumeration literal, implicitly declared (but noninherited)
            subprogram, null procedure, or an attribute that is a subprogram,
            an implicit body is assumed. For a dispatching call, 3.9.2, "
            Dispatching Operations of Tagged Types" defines which
            subprogram_body is executed.

10.1/2 {AI95-00407-01} If the name or prefix of a subprogram call denotes a
prefixed view (see 4.1.3), the subprogram call is equivalent to a call on the
underlying subprogram, with the first actual parameter being provided by the
prefix of the prefixed view (or the Access attribute of this prefix if the
first formal parameter is an access parameter), and the remaining actual
parameters given by the actual_parameter_part, if any.

11/2 {AI95-00318-02} The exception Program_Error is raised at the point of a
function_call if the function completes normally without executing a return
statement.

11.a        Discussion: We are committing to raising the exception at the
            point of call, for uniformity - see AI83-00152. This happens after
            the function is left, of course.

11.b        Note that there is no name for suppressing this check, since the
            check imposes no time overhead and minimal space overhead (since
            it can usually be statically eliminated as dead code).

12/2 {AI95-00231-01} A function_call denotes a constant, as defined in 6.5;
the nominal subtype of the constant is given by the nominal subtype of the
function result.


                                  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    {AI05-0299-1}
        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    {AI05-0299-1} Pair;
        Pair(Left => new Person(F), Right => new Person(M));

        NOTES

24      9  If a default_expression is used for two or more parameters in a
        multiple parameter_specification, the default_expression is evaluated
        once for each omitted parameter. Hence in the above examples, the two
        calls of Pair are equivalent.


                                  Examples

25  Examples of overloaded subprograms:

26      procedure Put(X : in Integer);
        procedure Put(X : in String);

27      procedure Set(Tint   : in Color);
        procedure Set(Signal : in Light);

28  Examples of their calls:

29      Put(28);
        Put("no possible ambiguity here");

30      Set(Tint   => Red);
        Set(Signal => Red);
        Set(Color'(Red));

31      --  Set(Red) would be ambiguous since Red may
        --  denote a value either of type Color or of type Light


                         Wording Changes from Ada 83

31.a        We have gotten rid of parameters "of the form of a type
            conversion" (see RM83-6.4.1(3)). The new view semantics of type_conversions
            allows us to use normal type_conversions instead.

31.b        We have moved wording about run-time semantics of parameter
            associations to 6.4.1.

31.c        We have moved wording about raising Program_Error for a function
            that falls off the end to here from RM83-6.5.


                            Extensions to Ada 95

31.d/2      {AI95-00310-01} Nondispatching abstract operations are no longer
            considered when resolving a subprogram call. That makes it
            possible to use abstract to "undefine" a predefined operation for
            an untagged type. That's especially helpful when defining custom
            arithmetic packages.


                         Wording Changes from Ada 95

31.e/2      {AI95-00231-01} Changed the definition of the nominal subtype of a
            function_call to use the nominal subtype wording of 6.1, to take
            into account null_exclusions and access result types.

31.f/2      {AI95-00345-01} Added wording to clarify that the meaning of a
            call on a subprogram "implemented by" an entry or protected
            operation is defined by 3.9.2.

31.g/2      {AI95-00407-01} Defined the meaning of a call on a prefixed view
            of a subprogram (see 4.1.3).


6.4.1 Parameter Associations


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


                         Language Design Principles

1.a         The parameter passing rules for out parameters are designed to
            ensure that the parts of a type that have implicit initial values
            (see 3.3.1) don't become "de-initialized" by being passed as an
            out parameter.

1.b/3       {AI05-0142-4} For explicitly aliased parameters of functions, we
            will ensure at the call site that a part of the parameter can be
            returned as part of the function result without creating a
            dangling pointer. We do this with accessibility checks at the call
            site that all actual objects of explicitly aliased parameters live
            at least as long as the function result; then we can allow them to
            be returned as access discriminants or anonymous access results,
            as those have the master of the function result.


                            Name Resolution Rules

2/3 {AI05-0118-1} 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.

2.a/3       To be honest: {AI05-0118-1} For positional parameters, the "
            corresponding position" is calculated after any transformation of
            prefixed views.

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.

3.a         To be honest: The corresponding default_expression is the one of
            the corresponding formal parameter in the profile of the view
            denoted by the name or prefix of the call.

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

4.a/4       Ramification: {AI12-0005-1} This formally resolves the ambiguity
            present in the syntax rule for explicit_actual_parameter. This
            matters as an expression that is a name is evaluated and
            represents a value while a name by itself can be an object; if the
            mode is not in, we want the parameter to interpreted as an object.
            Note that we don't actually require that the actual be a name if
            the mode is not in; we do that below.

4.b/4       {AI12-0005-1} This wording uses "interpreted as" rather than
            "shall be" so that this rule is not used to resolve overloading;
            it is solely about evaluation as described above. We definitely do
            not want to allow oddities like the presence of parentheses
            requiring the selection of an in formal parameter as opposed to an
            otherwise matching in out parameter.


                               Legality Rules

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

5.a         Discussion: We no longer need "or a type_conversion whose argument
            is the name of a variable," because a type_conversion is now a
            name, and a type_conversion of a variable is a variable.

5.b         Reason: The requirement that the actual be a (variable) name is
            not an overload resolution rule, since we don't want the
            difference between expression and name to be used to resolve
            overloading. For example:

5.c             procedure Print(X : in Integer; Y : in Boolean := True);
                procedure Print(Z : in out Integer);
                . . .
                Print(3); -- Ambiguous!
                  

5.d         The above call to Print is ambiguous even though the call is not
            compatible with the second Print which requires an actual that is
            a (variable) name ("3" is an expression, not a name). This
            requirement is a legality rule, so overload resolution fails
            before it is considered, meaning that the call is ambiguous.

5.1/4 {AI12-0074-1} {AI12-0159-1} 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 {AI12-0074-1} {AI12-0159-1} 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.

5.e/4       Reason: These rules are needed in order to ensure that a
            well-defined parameter value is passed.

6/3 {AI05-0102-1} {AI05-0142-4} 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.a/3       Ramification: Tagged objects (and tagged aggregates for in
            parameters) do not need to be aliased. This matches the behavior
            of unaliased formal parameters of tagged types, which allow
            'Access to be taken of the formal parameter regardless of the form
            of the actual parameter.

6.b/3       Reason: We need the subtype check on untagged actual parameters so
            that the requirements of 'Access are not lost. 'Access makes its
            checks against the nominal subtype of its prefix, and parameter
            passing can change that subtype. But we don't want this parameter
            passing to change the objects that would be allowed as the prefix
            of 'Access. This is particularly important for arrays, where we
            don't want to require any additional implementation burden.

6.b.1/4     Discussion: {AI12-0095-1} We assume the worst in a generic body
            whether or not a formal subtype has a constrained partial view;
            specifically, in a generic body a discriminated subtype is
            considered to have a constrained partial view if it is a
            descendant of an untagged generic formal private or derived type
            (see 12.5.1 for the formal definition of this rule).

6.3/4 {AI12-0095-1} 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 {AI05-0142-4} {AI05-0234-1} 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.c/3       Discussion: Since explicitly aliased parameters are either tagged
            or required to be objects, there is always an object (possibly
            anonymous) to talk about. This is discussing the static
            accessibility level of the actual object; it does not depend on
            any runtime information (for instance when the actual object is a
            formal parameter of another subprogram, it does not depend on the
            actual parameter of that other subprogram).

6.d/4       Ramification: {AI12-0095-1} This accessibility check (and its
            dynamic cousin as well) can only fail if the master of the
            function call (which is defined in the Heart of Darkness, or
            3.10.2 if you prefer) is different than the master directly
            enclosing the call. The most likely place where this will occur is
            in the initializer of an allocator; in almost all other cases this
            check will always pass.

6.5/3 {AI05-0144-2} 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.e/3       Reason: This exposes known renamings of slices, indexing, and so
            on to this definition. In particular, if we have

6.f/3           C : Character renames S(1);

6.g/3       then C and S(1) are known to denote the same object.

6.h/3       We need the requirement that no variables occur in the prefixes of
            dereferences and in (index) expressions of the renamed object in
            order to avoid problems from later changes to those parts of
            renamed names. Consider:

6.i/3              type Ref is access Some_Type;
                   Ptr : Ref := new Some_Type'(...);
                   X : Some_Type renames Ptr.all;
                begin
                   Ptr := new Some_Type'(...);
                   P (Func_With_Out_Params (Ptr.all), X);

6.j/3       X and Ptr.all should not be known to denote the same object, since
            they denote different allocated objects (and this is not an
            unreasonable thing to do).

6.k/3       To be honest: The exclusion of variables from renamed object_names
            is not enough to prevent altering the value of the name or
            expression by another access path. For instance, both in
            parameters passed by reference and access-to-constant values can
            designate variables. For the intended use of "known to be the same
            object", this is OK; the modification via another access path is
            very tricky and it is OK to reject code that would be buggy except
            for the tricky code. Assuming Element is an elementary type,
            consider the following example:

6.l/3           Global : Tagged_Type;

6.m/3           procedure Foo (Param : in Tagged_Type := Global) is
                   X : Element renames Some_Global_Array (Param.C);
                begin
                   Global.C := Global.C + 1;
                   Swap (X, Some_Global_Array (Param.C));

6.n/3       The rules will flag the call of procedure Swap as illegal, since X
            and Some_Global_Array (Parameter.C) are known to denote the same
            object (even though they will actually represent different objects
            if Param = Global). But this is only incorrect if the parameter
            actually is Global and not some other value; the error could exist
            for some calls. So this flagging seems harmless.

6.o/3       Similar examples can be constructed using stand-alone composite
            constants with controlled or immutably limited components, and (as
            previously noted) with dereferences of access-to-constant values.
            Even when these examples flag a call incorrectly, that call
            depends on very tricky code (modifying the value of a constant);
            the code is likely to confuse future maintainers as well and thus
            we do not mind rejecting it.

6.p/3       Discussion: Whether or not names or prefixes are known to denote
            the same object is determined statically. If the name contains
            some dynamic portion other than a dereference, indexed_component,
            or slice, it is not "known to denote the same object".

6.q/3       These rules make no attempt to handle slices of objects that are
            known to be the same when the slices have dynamic bounds (other
            than the trivial case of bounds being defined by the same
            subtype), even when the bounds could be proven to be the same, as
            it is just too complex to get right and these rules are intended
            to be conservative.

6.r/3       Ramification: "Known to denote the same object" is intended to be
            an equivalence relationship, that is, it is reflexive, symmetric,
            and transitive. We believe this follows from the rules. For
            instance, given the following declarations:

6.s/3           S   : String(1..10);
                ONE : constant Natural := 1;
                R   : Character renames S(1);

6.t/3       the names R and S(1) are known to denote the same object by the
            sixth bullet, and S(1) and S(ONE) are known to denote the same
            object by the fourth bullet, so using the sixth bullet on R and
            S(ONE), we simply have to test S(1) vs. S(ONE), which we already
            know denote the same object.

6.12/3 {AI05-0144-2} 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.u/3       Reason: This ensures that names Prefix.Comp and Prefix are known
            to refer to the same object for the purposes of the rules below.
            This intentionally does not include dereferences; we only want to
            worry about accesses to the same object, and a dereference changes
            the object in question. (There is nothing shared between an access
            value and the object it designates.)

6.16/3 {AI05-0144-2} 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/3   * For each name N 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.v/3       To be honest: This means visibly an elementary type; it does not
            include partial views of elementary types (partial views are
            always composite). That's necessary to avoid having
            Legality Rules depend on the contents of the private part.

6.18/3 {AI05-0144-2} 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.w/3       Ramification: All of the places where the language allows an
            arbitrary order can be found by looking in the index under
            "arbitrary order, allowed". Note that this listing includes places
            that don't involve names or expressions (such as checks or
            finalization).

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.x/3       Ramification: This requirement cannot fail for a procedure or
            entry call alone; there must be at least one function with an in
            out or out parameter called as part of a parameter expression of
            the call in order for it to fail.

6.y/3       Reason: These rules prevent obvious cases of dependence on the
            order of evaluation of names or expressions. Such dependence is
            usually a bug, and in any case, is not portable to another
            implementation (or even another optimization setting).

6.z/3       In the case that the top-level construct C is a call, these rules
            do not require checks for most in out parameters, as the rules
            about evaluation of calls prevent problems. Similarly, we do not
            need checks for short circuit operations or other operations with
            a defined order of evaluation. The rules about arbitrary order
            (see 1.1.4) allow evaluating parameters and writing parameters
            back in an arbitrary order, but not interleaving of evaluating
            parameters of one call with writing parameters back from another -
            that would not correspond to any allowed sequential order.

6.20/3 {AI05-0144-2} 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.

6.aa/3      Ramification: We do not check expressions that are evaluated only
            because of a component initialized by default in an aggregate (via
            <>).


                              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.

10.a        Discussion: We are always allowing sliding, even for [in] out
            by-reference parameters.

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.

11.a        Ramification: The conversion mentioned here is a value conversion.

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

13/3      * {AI05-0153-3} {AI05-0196-1} 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.a        Reason: This preserves the Language Design Principle that an
            object of an access type is always initialized with a "
            reasonable" value.

13.1/4    * {AI05-0153-3} {AI05-0228-1} {AI12-0074-1} {AI12-0159-1} 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        * {AI12-0074-1} 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        * {AI12-0074-1} the Default_Value aspect is unspecified for the
                type of the operand of the conversion

13.4/4      {AI12-0074-1} then Program_Error is raised;

13.b/3      Reason: This preserves the Language Design Principle that all
            objects of a type with an implicit initial value are initialized.
            This is important so that a programmer can guarantee that all
            objects of a scalar type have a valid value with a carefully
            chosen Default_Value.

13.c/3      Implementation Note: This rule means that out parameters of a
            subtype T with a specified Default_Value need to be large enough
            to support any possible value of the base type of T. In contrast,
            a type that does not have a Default_Value only need support the
            size of the subtype (since no values are passed in).

13.d/4      Discussion: The Program_Error case can only occur in the body of
            an instance of a generic unit. Legality Rules will catch all other
            cases. Implementations that macro-expand generics can always
            detect this case when the enclosing instance body is expanded.

14        * For a composite type with discriminants or that has implicit
            initial values for any subcomponents (see 3.3.1), the behavior is
            as for an in out parameter passed by copy.

14.a        Reason: This ensures that no part of an object of such a type can
            become "de-initialized" by being part of an out parameter.

14.b        Ramification: This includes an array type whose component type is
            an access type, and a record type with a component that has a
            default_expression, among other things.

15        * For any other type, the formal parameter is uninitialized. If
            composite, a view conversion of the actual parameter to the
            nominal subtype of the formal is evaluated [(which might raise
            Constraint_Error)], and the actual subtype of the formal is that
            of the view conversion. If elementary, the actual subtype of the
            formal is given by its nominal subtype.

15.a/3      Ramification: {AI05-0228-1} This case covers scalar types that do
            not have Default_Value specified, and composite types whose
            subcomponent's subtypes do not have any implicit initial values.
            The view conversion for composite types ensures that if the
            lengths don't match between an actual and a formal array
            parameter, the Constraint_Error is raised before the call, rather
            than after.

15.1/3   * {AI05-0142-4} {AI05-0234-1} 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).

15.a.1/3    Ramification: If the actual object to a call C is a formal
            parameter of some function call F, no dynamic check against the
            master of the actual parameter of F is necessary. Any case which
            could fail the dynamic check is already statically illegal (either
            at the call site of F, or at the call site C). This is important,
            as it would require nasty distributed overhead to accurately know
            the dynamic accessibility of a formal parameter (all tagged and
            explicitly aliased parameters would have to carry accessibility
            levels).

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.

17.a        Ramification: The conversions mentioned above during parameter
            passing might raise Constraint_Error - (see 4.6).

17.b        Ramification: If any conversion or assignment as part of parameter
            passing propagates an exception, the exception is raised at the
            place of the subprogram call; that is, it cannot be handled inside
            the subprogram_body.

17.c        Proof: Since these checks happen before or after executing the
            subprogram_body, the execution of the subprogram_body does not
            dynamically enclose them, so it can't handle the exceptions.

17.d        Discussion: The variable we're talking about is the one denoted by
            the variable_name given as the explicit_actual_parameter. If this
            variable_name is a type_conversion, then the rules in 4.6 for
            assigning to a view conversion apply. That is, if X is of subtype
            S1, and the actual is S2(X), the above-mentioned conversion will
            convert to S2, and the one mentioned in 4.6 will convert to S1.


                             Erroneous Execution

18/3 {AI05-0008-1} 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).


                            Extensions to Ada 83

18.a        In Ada 95, a program can rely on the fact that passing an object
            as an out parameter does not "de-initialize" any parts of the
            object whose subtypes have implicit initial values. (This
            generalizes the RM83 rule that required copy-in for parts that
            were discriminants or of an access type.)


                         Wording Changes from Ada 83

18.b/3      {AI05-0299-1} We have eliminated the subclause on Default
            Parameters, as it is subsumed by earlier subclauses.


                        Inconsistencies With Ada 2005

18.c/3      {AI05-0196-1} Correction: Clarified that out parameters of an
            access type are not checked for null exclusions when they are
            passed in (which is similar to the behavior for constraints). This
            was unspecified in Ada 2005, so a program which depends on the
            behavior of an implementation which does check the exclusion may
            malfunction. But a program depending on an exception being raised
            is unlikely.


                       Incompatibilities With Ada 2005

18.d/3      {AI05-0144-2} Additional rules have been added to make illegal
            passing the same elementary object to more than one in out or out
            parameters of the same call. In this case, the result in the
            object could depend on the compiler version, optimization
            settings, and potentially the phase of the moon, so this check
            will mostly reject programs that are nonportable and could fail
            with any change. Even when the result is expected to be the same
            in both parameters, the code is unnecessarily tricky. Programs
            which fail this new check should be rare and are easily fixed by
            adding a temporary object.


                        Wording Changes from Ada 2005

18.e/3      {AI05-0008-1} Correction: A missing rule was added to cover cases
            that were missed in Ada 95 and Ada 2005; specifically, that an in
            parameter passed by reference might have its discriminants changed
            via another path. Such cases are erroneous as requiring compilers
            to detect such errors would be expensive, and requiring such cases
            to work would be a major change of the user model (in parameters
            with discriminants could no longer be assumed constant). This is
            not an inconsistency, as compilers are not required to change any
            current behavior.

18.f/3      {AI05-0102-1} Correction: Moved implicit conversion
            Legality Rule to 8.6.

18.g/3      {AI05-0118-1} Correction: Added a definition for positional
            parameters, as this is missing from Ada 95 and later.

18.h/3      {AI05-0142-4} Rules have been added defining the legality and
            dynamic checks needed for explicitly aliased parameters (see 6.1).

18.i/3      {AI05-0144-2} Additional rules have been added such that passing
            an object to an in out or out parameter of a function is illegal
            if it is used elsewhere in a construct which allows evaluation in
            an arbitrary order. Such calls are not portable (since the results
            may depend on the evaluation order), and the results could even
            vary because of optimization settings and the like. Thus they've
            been banned.


                       Incompatibilities With Ada 2012

18.j/4      {AI12-0074-1} {AI12-0159-1} Corrigendum: Added rules to ensure
            that the value passed into a out parameter for elementary types is
            well-defined in the case of a view conversion. The new rules can
            be incompatible. For a view conversion to an unrelated type with
            the Default_Value aspect specified, the aspect is new in Ada 2012
            so it should be unlikely to occur in existing code. For a view
            conversion to an unrelated access type, the incompatibility is
            possible as this could be written in Ada 95, but such a view
            conversion is thought to be rare. In both cases, declaring and
            passing a temporary rather than a view conversion will eliminate
            the problem.

18.k/4      {AI12-0095-1} Corrigendum: Because of a rule added in 12.5.1, the
            checks for the passing of an object to an explicitly aliased
            parameter in a generic body were strengthened to use an assume the
            worst rule. This case is rather unlikely as a formal private or
            derived type with discriminants is required along with an
            explicitly aliased parameter whose type doesn't statically match
            the formal type. Such a program is very unlikely, especially as
            explicitly aliased parameters are a new Ada 2012 feature.


6.5 Return Statements


1/2 {AI95-00318-02} 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     {AI95-00318-02} simple_return_statement ::= return [expression];

2.1/3   {AI05-0277-1} extended_return_object_declaration ::= 
            defining_identifier
         : [aliased][constant] return_subtype_indication [:= expression]

2.2/3   {AI95-00318-02} {AI05-0015-1} {AI05-0053-1} {AI05-0277-1}
        {AI05-0299-1} extended_return_statement ::= 
            return extended_return_object_declaration [do
                handled_sequence_of_statements
            end return];

2.3/2   {AI95-00318-02} return_subtype_indication ::= subtype_indication
         | access_definition


                            Name Resolution Rules

3/2 {AI95-00318-02} 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_statement is that of the return_subtype_indication.

3.a         To be honest: The same applies to generic functions.


                               Legality Rules

4/2 {AI95-00318-02} 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.

4.a/4       To be honest: {AI12-0089-1} The above also applies to generic
            subprograms, even though they are not callable constructs. (An
            instance of a generic subprogram is a callable construct, but not
            a generic subprogram itself.)

5/3 {AI95-00318-02} {AI05-0015-1} 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_statement with the reserved word constant shall include an
expression.

5.a/4       Reason: {AI95-00318-02} {AI12-0022-1} The requirement that a
            function body has to have at least one return statement is a "
            helpful" restriction. There has been some interest in lifting this
            restriction, or allowing a raise statement to substitute for the
            return statement. However, there was enough interest in leaving it
            as is that we decided not to change it. Note that for Ada 2012,
            Corrigendum 1, a return statement whose expression is a
            raise_expression can be given in any function body (the
            raise_expression will match any type), so there is much less need
            to eliminate this rule.

5.b/2       Ramification: {AI95-00318-02} A return statement can apply to an
            extended_return_statement, so a simple_return_statement without an
            expression can be given in one. However, neither simple_return_-
            statement with an expression nor an extended_return_statement can
            be given inside an extended_return_statement, as they must apply
            (directly) to a function body.

5.b.1/4     {AI12-0089-1} Since a "function body" includes a generic function
            body, this rule and all of the following Legality Rules apply to
            generic function bodies as well as non-generic function bodies.
            This is true even though a generic function is not a function.

5.1/2 {AI95-00318-02} For an extended_return_statement that applies to a
function body:

5.2/3   * {AI95-00318-02} {AI05-0032-1} {AI05-0103-1} 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.3/2   * {AI95-00318-02} If the result subtype of the function is defined by
        an access_definition, the return_subtype_indication shall be an
        access_definition. The subtype defined by the access_definition shall
        statically match the result subtype of the function. [The
        accessibility level of this anonymous access subtype is that of the
        result subtype.]

5.b.2/4     Proof: {AI12-0070-1} The accessibility of such anonymous access
            types is defined in the Heart of Darkness (aka 3.10.2).

5.4/3   * {AI05-0032-1} 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.b.3/3     Reason: In this case, the return_subtype_indication could be a
            specific type initialized by default; in that case there is no
            expression to check.

5.5/3 {AI95-00318-02} {AI05-0032-1} For any return statement that applies to a
function body:

5.6/3   * {AI95-00318-02} {AI05-0188-1} [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.c/3       This paragraph was deleted.{AI05-0188-1}

5.7/3   * {AI95-00416-01} {AI05-0032-1} {AI05-0051-1} 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.d/4       Discussion: {AI05-0032-1} {AI05-0051-1} {AI12-0005-1} If the
            result type is class-wide, then there must be an expression of the
            return statement unless this is an extended_return_statement whose
            return_subtype_indication is a specific type. We have a separate
            rule to cover that case. Note that if an
            extended_return_statement has an expression, then both this rule
            and the next one must be satisfied.

5.8/3   * {AI05-0051-1} 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.d.1/3     Discussion: We use the type used by the return statement rather
            than from the function return type since we want to check whenever
            the return object has access discriminants, even if the function
            return type doesn't have any (mostly for a class-wide type).

5.9/3 {AI05-0277-1} 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.10/3 {AI95-00318-02} {AI05-0015-1} {AI05-0144-2} 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.11/3 {AI95-00318-02} {AI95-00416-01} {AI05-0032-1} 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.

5.e/2       Ramification: If the result type is controlled or has a controlled
            part, appropriate calls on Initialize or Adjust are performed
            prior to executing the handled_sequence_of_statements, except when
            the initial expression is an aggregate (which requires
            build-in-place with no call on Adjust).

5.f/3       {AI05-0005-1} If the return statement is left without resulting in
            a return (for example, due to an exception propagated from the
            expression or the handled_sequence_of_statements, or a goto out of
            the handled_sequence_of_statements), if the return object has been
            created, it is finalized prior to leaving the return statement. If
            it has not been created when the return statement is left, it is
            not created or finalized.

5.g/3       {AI05-0032-1} Other rules ensure that the check required by this
            rule cannot fail unless the function has a class-wide result
            subtype where the associated specific subtype is constrained. In
            other cases, either the subtypes have to match or the function's
            subtype is unconstrained and needs no checking.

6/2 {AI95-00318-02} 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.

6.a         Ramification: The conversion might raise Constraint_Error - (see
            4.6).

7/2 {AI95-00318-02} {AI95-00416-01} [If the return object has any parts that
are tasks, the activation of those tasks does not occur until after the
function returns (see 9.2).]

7.a/2       Proof: This is specified by the rules in 9.2.

7.b/2       Reason: Only the caller can know when task activations should take
            place, as it depends on the context of the call. If the function
            is being used to initialize the component of some larger object,
            then that entire object must be initialized before any task
            activations. Even after the outer object is fully initialized,
            task activations are still postponed until the begin at the end of
            the declarative part if the function is being used to initialize
            part of a declared object.

8/4 {AI95-00318-02} {AI95-00344-01} {AI05-0024-1} {AI05-0032-1} {AI12-0097-1}
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.a/2       Ramification: {AI95-00318-02} The first sentence is true even if
            the tag of the expression is different, which could happen if the
            expression were a view conversion or a dereference of an access
            value. Note that for a limited type, because of the restriction to
            aggregates and function calls (and no conversions), the tag will
            already match.

8.b/2       Reason: {AI95-00318-02} The first rule ensures that a function
            whose result type is a specific tagged type always returns an
            object whose tag is that of the result type. This is important for
            dispatching on controlling result, and allows the caller to
            allocate the appropriate amount of space to hold the value being
            returned (assuming there are no discriminants).

8.c/3       The master check prevents the returned object from outliving its
            type. Note that this check cannot fail for a specific tagged type,
            as the tag represents the function's type, which necessarily must
            be declared outside of the function.

8.d/3       We can't use the normal accessibility level "deeper than" check
            here because we may have "incomparable" levels if the masters
            belong to two different tasks. This can happen when an accept
            statement calls a function declared in the enclosing task body,
            and the function returns an object passed to it from the accept
            statement, and this object was itself a parameter to the accept
            statement.

8.d.1/4     To be honest: {AI12-0097-1} The expression here is the return
            expression if the return statement is a simple_return_statement,
            and the initializing expression of the
            extended_return_object_declaration if the return statement is an
            extended_return_statement (ignoring any inner
            simple_return_statements, which necessarily cannot have an
            expression, and any other expressions inside of the
            extended_return_statement).

8.1/3 {AI05-0073-1} 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.

8.e/3       Reason: This check is needed so that dispatching on controlling
            access results works for tag-indeterminate functions. If it was
            not made, it would be possible for such functions to return an
            access to a descendant type, meaning the function could return an
            object with a tag different than the one assumed by the
            dispatching rules.

Paragraphs 9 through 20 were deleted.

21/3 {AI95-00318-02} {AI95-00402-01} {AI95-00416-01} {AI05-0051-1} 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.

21.a/2      This paragraph was deleted.

21.b/2      Reason: The check prevents the returned object (for a nonlimited
            type) from outliving the object designated by one of its
            discriminants. The check is made on the values of the
            discriminants, which may come from the return_subtype_indication
            (if constrained), or the expression, but it is never necessary to
            check both.

21.c/3      Implementation Note: {AI05-0234-1} The reason for saying "any part
            of the specific type" is to simplify implementation. In the case
            of class-wide result objects, this allows the testing of a simple
            flag in the tagged type descriptor that indicates whether the
            specific type has any parts with access discriminants. By basing
            the test on the type of the object rather than the object itself,
            we avoid concerns about whether subcomponents in variant parts and
            of arrays (which might be empty) are present.

21.d/3      Discussion: {AI05-0234-1} For a function with a class-wide result
            type, the access values that need to be checked are determined by
            the tag of the return object. In order to implement this
            accessibility check in the case where the tag of the result is not
            known statically at the point of the return statement, an
            implementation may need to somehow associate with the tag of a
            specific tagged type an indication of whether the type has
            unconstrained access discriminants (explicit or inherited) or has
            any subcomponents with such discriminants. If an implementation is
            already maintaining a statically initialized descriptor of some
            kind for each specific tagged type, then an additional Boolean
            could be added to this descriptor.

21.e/3      {AI05-0005-1} {AI05-0234-1} Note that the flag should only be
            queried in the case where the result object might have access
            discriminants that might have subtypes with "bad" accessibility
            levels (as determined by the rules of 3.10.2 for determining the
            accessibility level of the type of an access discriminant in the
            expression or return_subtype_indication of a return statement).

21.f/3      Thus, in a case like

21.g/3          type Global is access T'Class;
                function F (Ptr : Global) return T'Class is
                begin
                   return Ptr.all;
                end F;

21.h/3      there is no need for a run-time accessibility check. While an
            object of T'Class "might have" access discriminants, the
            accessibility of those potential discriminants cannot be bad. The
            setting of the bit doesn't matter and there is no need to query it.

21.i/3      On the other hand, given

21.j/3          function F return T'Class is
                   Local : T'Class := ... ;
                begin
                   return Local;
                end F;

21.k/3      In this case, a check would typically be required.

21.l/3      The need for including subcomponents in this check is illustrated
            by the following example:

21.m/3          X : aliased Integer;

21.n/3          type Component_Type (Discrim : access Integer := X'Access)
                   is limited null record;

21.o/3          type Undiscriminated is record
                   Fld : Component_Type;
                end record;

21.p/3          function F return Undiscriminated is
                   Local : aliased Integer;
                begin
                   return X : Undiscriminated := (Fld => (Discrim => Local'Access)) do
                      Foo;
                   end return;
                   -- raises Program_Error after calling Foo.
                end F;

21.q/3      Ramification: {AI05-0234-1} In the case where the tag of the
            result is not known statically at the point of the return
            statement and the run-time accessibility check is needed,
            discriminant values and array bounds play no role in performing
            this check. That is, array components are assumed to have nonzero
            length and components declared within variant parts are assumed to
            be present. Thus, the check may be implemented simply by testing
            the aforementioned descriptor bit and conditionally raising
            Program_Error.

22/3 {AI95-00318-02} {AI05-0058-1} 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.

22.a/3      Ramification: {AI05-0058-1} A transfer of control that completes
            an extended_return_statement (such as an exit or goto) does not
            cause a return to the caller unless it is caused by
            simple_return_statement (that is, triggers the second sentence of
            this paragraph). The return to the caller occurs for the
            simple_return_statement that applies to an
            extended_return_statement because the last sentence says "the
            normal completion of a simple_return_statement", which includes
            the one nested in the extended_return_statement.

23/2 {AI95-00318-02} In the case of a function, the function_call denotes a
constant view of the return object.


                         Implementation Permissions

24/3 {AI95-00416-01} {AI05-0050-1} 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   * {AI05-0050-1} 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   * {AI05-0050-1} 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).

24.a/3      Reason: {AI95-00416-01} {AI05-0050-1} Without such a permission,
            it would be very difficult to implement "built-in-place"
            semantics. The intention is that the exception is raised at the
            same point that it would have been raised without the permission;
            it should not change handlers if the implementation switches
            between return-by-copy and built-in-place. This means that the
            exception is not handleable within the function, because in the
            return-by-copy case, the constraint check to verify that the
            result satisfies the constraints of the object being initialized
            happens after the function returns. This implies further that upon
            detecting such a situation, the implementation may need to
            simulate a goto to a point outside any local exception handlers
            prior to raising the exception.

24.b/3      Ramification: {AI95-00416-01} {AI05-0050-1} These permissions do
            not apply in the case of an extended return object with mutable
            discriminants. That's necessary because in that case a return
            object can be created with the "wrong" discriminants and then
            changed to the "right" discriminants later (but before returning).
            We don't want this case raising an exception when the canonical
            semantics will not do so.

24.c/3      {AI05-0050-1} It's still possible to write a program that will
            raise an exception using this permission that would not in the
            canonical semantics. That could happen if a return statement with
            the "wrong" discriminants or bounds is abandoned (via an
            exception, or for an extended_return_statement, via an exit or
            goto statement), and then a return statement with the "right"
            discriminants or bounds is executed. The only solution for this
            problem is to not have the permission at all, but this is too
            unusual of a case to worry about the effects of the permission,
            especially given the implementation difficulties for
            built-in-place objects that this permission is intended to ease.

24.d/3      {AI05-0050-1} Note that the mutable-discriminant case only happens
            when built-in-place initialization is optional. This means that
            any difficulties associated with implementing built-in-place
            initialization without these permissions can be sidestepped by not
            building in place.


                                  Examples

25  Examples of return statements:

26/2    {AI95-00318-02}
        return;                         -- in a procedure body, entry_body,
                                        -- accept_statement
        , or extended_return_statement

27      return Key_Value(Last_Index);   -- in a function body

28/2    {AI95-00318-02}
        return Node : Cell do           -- in a function body, see 3.10.1
         for Cell
           Node.Value := Result;
           Node.Succ := Next_Node;
        end return;


                        Incompatibilities With Ada 83

28.a/2      {AI95-00318-02} In Ada 95, if the result type of a function has a
            part that is a task, then an attempt to return a local variable
            will raise Program_Error. This is illegal in Ada 2005, see below.
            In Ada 83, if a function returns a local variable containing a
            task, execution is erroneous according to AI83-00867. However,
            there are other situations where functions that return tasks (or
            that return a variant record only one of whose variants includes a
            task) are correct in Ada 83 but will raise Program_Error according
            to the new rules.

28.b        The rule change was made because there will be more types
            (protected types, limited controlled types) in Ada 95 for which it
            will be meaningless to return a local variable, and making all of
            these erroneous is unacceptable. The current rule was felt to be
            the simplest that kept upward incompatibilities to situations
            involving returning tasks, which are quite rare.


                         Wording Changes from Ada 83

28.c/3      {AI05-0299-1} This subclause has been moved here from chapter 5,
            since it has mainly to do with subprograms.

28.d        A function now creates an anonymous object. This is necessary so
            that controlled types will work.

28.e/2      {AI95-00318-02} We have clarified that a return statement applies
            to a callable construct, not to a callable entity.

28.f/2      {AI95-00318-02} There is no need to mention generics in the rules
            about where a return statement can appear and what it applies to;
            the phrase "body of a subprogram or generic subprogram" is
            syntactic, and refers exactly to "subprogram_body".


                         Inconsistencies With Ada 95

28.f.1/3    {AI95-0416-1} {AI05-0005-1} {AI05-0050-1} Added an
            Implementation Permission allowing early raising of
            Constraint_Error if the result cannot fit in the ultimate object.
            This gives implementations more flexibility to do built-in-place
            returns, and is essential for limited types (which cannot be built
            in a temporary). However, it allows raising Constraint_Error in
            some cases where it would not be raised if the permission was not
            used. See Inconsistencies With Ada 2005 for additional changes.
            This case is potentially inconsistent with Ada 95, but a compiler
            does not have to take advantage of these permissions for any Ada
            95 code, so there should be little practical impact.


                        Incompatibilities With Ada 95

28.g/2      {AI95-00318-02} The entire business about return-by-reference
            types has been dropped. Instead, the expression of a return
            statement of a limited type can only be an aggregate or
            function_call (see 7.5). This means that returning a global object
            or type_conversion, legal in Ada 95, is now illegal. Such
            functions can be converted to use anonymous access return types by
            adding access in the function definition and return statement,
            adding .all in uses, and adding aliased in the object
            declarations. This has the advantage of making the reference
            return semantics much clearer to the casual reader.

28.h/2      We changed these rules so that functions, combined with the new
            rules for limited types (7.5), can be used as build-in-place
            constructors for limited types. This reduces the differences
            between limited and nonlimited types, which will make limited
            types useful in more circumstances.


                            Extensions to Ada 95

28.i/2      {AI95-00318-02} The extended_return_statement is new. This
            provides a name for the object being returned, which reduces the
            copying needed to return complex objects (including no copying at
            all for limited objects). It also allows component-by-component
            construction of the return object.


                         Wording Changes from Ada 95

28.j/2      {AI95-00318-02} The wording was updated to support anonymous
            access return subtypes.

28.k/2      {AI95-00318-02} The term "return expression" was dropped because
            reviewers found it confusing when applied to the default
            expression of an extended_return_statement.

28.l/2      {AI95-00344-01} {AI95-00416-01} Added accessibility checks to
            class-wide return statements. These checks could not fail in Ada
            95 (as all of the types had to be declared at the same level, so
            the tagged type would necessarily have been at the same level as
            the type of the object).

28.m/2      {AI95-00402-01} {AI95-00416-01} Added accessibility checks to
            return statements for types with access discriminants. Since such
            types have to be limited in Ada 95, the expression of a return
            statement would have been illegal in order for this check to fail.


                        Inconsistencies With Ada 2005

28.n/3      {AI05-0050-1} Correction: The Implementation Permission allowing
            early raising of Constraint_Error was modified to remove the most
            common of these cases from the permission (returning an object
            with mutable discriminants, where the return object is created
            with one set of discriminants and then changed to another). (The
            permission was also widened to allow the early check for
            constrained functions when that constraint is wrong.) However,
            there still is an unlikely case where the permission would allow
            an exception to be raised when none would be raised by the
            canonical semantics (when a return statement is abandoned). These
            changes can only remove the raising of an exception (or change the
            place where it is raised) compared to Ada 2005, so programs that
            depend on the previous behavior should be very rare.

28.o/3      {AI05-0051-1} {AI05-0234-1} Correction: Accessibility checks for
            access discriminants now depend on the master of the call rather
            than the point of declaration of the function. This will result in
            cases that used to raise Program_Error now running without raising
            any exception. This is technically inconsistent with Ada 2005 (as
            defined by Amendment 1), but it is unlikely that any real code
            depends on the raising of this exception.

28.p/3      {AI05-0073-1} Correction: Added a tag check for functions
            returning anonymous access-to-tagged types, so that dispatching of
            tag-indeterminate function works as expected. This is technically
            inconsistent with Ada 2005 (as defined by Amendment 1), but as the
            feature in question was newly added to Ada 2005, there should be
            little code that depends on the behavior that now raises an
            exception.


                       Incompatibilities With Ada 2005

28.q/3      {AI05-0053-1} {AI05-0277-1} Correction: The aliased keyword can
            now only appear on extended return objects with an immutably
            limited type. Other types would provide a way to get an aliased
            view of an object that is not necessarily aliased, which would be
            very bad. This is incompatible, but since the feature was added in
            Ada 2005, the keyword had no defined meaning in Ada 2005 (a
            significant oversight), and most sensible uses involve immutably
            limited types, it is unlikely that it appears meaningfully in
            existing programs.

28.r/3      {AI05-0103-1} Correction: Added wording to require static matching
            for unconstrained access types in extended return statements. This
            disallows adding or omitting null exclusions, and adding access
            constraints, in the declaration of the return object. While this
            is incompatible, the incompatible cases in question are either
            useless (access constraints - the constraint can be given on an
            allocator if necessary, and still must be given there even if
            given on the return object) or wrong (null exclusions - null could
            be returned from a function declared to be null excluding), so we
            expect them to be extremely rare in practice.


                           Extensions to Ada 2005

28.s/3      {AI05-0015-1} {AI05-0144-2} The return object of an
            extended_return_statement can be declared constant; this works
            similarly to a constant object declaration.

28.t/3      {AI05-0032-1} Added wording to allow the
            return_subtype_indication to have a specific type if the return
            subtype of the function is class-wide. Specifying the (specific)
            type of the return object is awkward without this change, and this
            is consistent with the way allocators work.


                        Wording Changes from Ada 2005

28.u/3      {AI05-0024-1} Correction: Corrected the master check for tags
            since the masters may be for different tasks and thus incomparable.

28.v/3      {AI05-0058-1} Correction: Corrected the wording defining returns
            for extended_return_statements, since leaving by an exit or goto
            is considered "normal" completion of the statement.

28.w/3      {AI05-0205-1} {AI05-0277-1} Correction: Added the
            extended_return_object_declaration to make other rules easier to
            write and eliminate the problem described in AI05-0205-1.


                        Wording Changes from Ada 2012

28.x/4      {AI05-0097-1} Corrigendum: Clarified the wording so that it is
            clear where the tag of the return object comes from. While a
            literal reading of the original Ada 2012 rule could have caused
            some weird results (by using some nearby subtype_indication to
            provide the tag in the case of a simple_return_statement, such a
            reading would be so unlike the rest of the language that we do not
            believe anyone would ever have thought it was intended. As such,
            we do not believe any implementation ever did this wrong (at least
            because of the old wording), and thus do not document this as a
            possible inconsistency.


6.5.1 Nonreturning Procedures


1/3 {AI95-00329-01} {AI95-00414-01} {AI05-0229-1} Specifying aspect No_Return
to have the value True indicates that a procedure cannot return normally[; it
may propagate an exception or loop forever].

1.a/3       Discussion: Aspect No_Deposit will have to wait for Ada 2020. :-)

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


                              Static Semantics

3.1/3 {AI05-0229-1} For a procedure or generic procedure, 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.a/3       Aspect Description for No_Return: A procedure will not return
            normally.

3.4/3 {AI05-0229-1} If a generic procedure is nonreturning, then so are its
instances. If a procedure declared within a generic unit is nonreturning, then
so are the corresponding copies of that procedure in instances.


                               Legality Rules

4/3 {AI95-00329-01} {AI95-00414-01} {AI05-0229-1} Aspect No_Return shall not
be specified for a null procedure nor an instance of a generic unit.

4.a/2       Reason: A null procedure cannot have the appropriate nonreturning
            semantics, as it does not raise an exception or loop forever.

4.b/3       Ramification: {AI05-0229-1} The procedure can be abstract. If a
            nonreturning procedure is renamed (anywhere) calls through the new
            name still have the nonreturning semantics.

5/2 {AI95-00329-01} {AI95-00414-01} A return statement shall not apply to a
nonreturning procedure or generic procedure.

6/2 {AI95-00414-01} A procedure shall be nonreturning if it overrides a
dispatching nonreturning procedure. In addition to the places where
Legality Rules normally apply (see 12.3), this rule applies also in the
private part of an instance of a generic unit.

6.a/2       Reason: This ensures that dispatching calls to nonreturning
            procedures will, in fact, not return.

7/2 {AI95-00414-01} If a renaming-as-body completes a nonreturning procedure
declaration, then the renamed procedure shall be nonreturning.

7.a/2       Reason: This ensures that no extra code is needed to implement the
            renames (that is, no wrapper is needed) as the body has the same
            property.

Paragraph 8 was deleted.


                              Dynamic Semantics

9/2 {AI95-00329-01} {AI95-00414-01} If the body of a nonreturning procedure
completes normally, Program_Error is raised at the point of the call.

9.a/2       Discussion: Note that there is no name for suppressing this check,
            since the check represents a bug, imposes no time overhead, and
            minimal space overhead (since it can usually be statically
            eliminated as dead code).

9.b/2       Implementation Note: If a nonreturning procedure tries to return,
            we raise Program_Error. This is stated as happening at the call
            site, because we do not wish to allow the procedure to handle the
            exception (and then, perhaps, try to return again!). However, the
            expected run-time model is that the compiler will generate raise
            Program_Error at the end of the procedure body (but not handleable
            by the procedure itself), as opposed to doing it at the call site.
            (This is just like the typical run-time model for functions that
            fall off the end without returning a value). The reason is
            indirect calls: in P.all(...);, the compiler cannot know whether P
            designates a nonreturning procedure or a normal one. Putting the
            raise Program_Error in the procedure's generated code solves this
            problem neatly.

9.c/2       Similarly, if one passes a nonreturning procedure to a generic
            formal parameter, the compiler cannot know this at call sites (in
            shared code implementations); the raise-in-body solution deals
            with this neatly.


                                  Examples

10/3    {AI95-00433-01} {AI05-0229-1}
        procedure Fail(Msg : String)  -- raises Fatal_Error exception
           with No_Return;
           -- Inform compiler and reader that procedure never returns normally


                            Extensions to Ada 95

10.a/2      {AI95-00329-01} {AI95-00414-01} Pragma No_Return is new.


                           Extensions to Ada 2005

10.b/3      {AI05-0229-1} Aspect No_Return is new; pragma No_Return is now
            obsolescent.


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

2.a/3       To be honest: {AI05-0299-1} We also use the term operator (in
            Clause 4 and in 6.1) to refer to one of the syntactic categories
            defined in 4.5, "Operators and Expression Evaluation" whose names
            end with "_operator:" logical_operator, relational_operator,
            binary_adding_operator, unary_adding_operator, multiplying_-
            operator, and highest_precedence_operator.

2.b/3       Discussion: {AI05-0005-1} This equivalence extends to uses of
            function_call in most other language rules. However, as often
            happens, the equivalence is not perfect, as operator calls are not
            a name, while a function_call is a name. Thus, operator calls
            cannot be used in contexts that require a name (such as a rename
            of an object). A direct fix for this problem would be very
            disruptive, and thus we have not done that. However, qualifying an
            operator call can be used as a workaround in contexts that require
            a name.


                               Legality Rules

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

6.a/3       Discussion: {AI05-0128-1} A "/=" defined by this rule is
            considered user-defined, which means that it will be inherited by
            a derived type. "User-defined" means "not language-defined" for
            the purposes of inheritance, that is anything other than
            predefined operators.

        NOTES

7       10  The operators "+" and "-" are both unary and binary operators, and
        hence may be overloaded with both one- and two-parameter functions.


                                  Examples

8   Examples of user-defined operators:

9       function "+" (Left, Right : Matrix) return Matrix;
        function "+" (Left, Right : Vector) return Vector;
        
        --  assuming that A, B, and C are of the type Vector
        --  the following two statements are equivalent:
        
        A := B + C;
        A := "+"(B, C);


                            Extensions to Ada 83

9.a         Explicit declarations of "=" are now permitted for any combination
            of parameter and result types.

9.b         Explicit declarations of "/=" are now permitted, so long as the
            result type is not Boolean.


                        Wording Changes from Ada 2005

9.c/3       {AI05-0128-1} Correction: Corrected the wording so that only
            explicit declarations of "=" cause an implicit declaration of
            "/="; otherwise, we could get multiple implicit definitions of
            "/=" without an obvious way to chose between them.

9.d/3       {AI05-0143-1} Added wording so that operators only allow
            parameters of mode in. This was made necessary by the elimination
            elsewhere of the restriction that function parameters be only of
            mode in.


6.7 Null Procedures


1/2 {AI95-00348-01} A null_procedure_declaration provides a shorthand to
declare a procedure with an empty body.


                                   Syntax

2/3     {AI95-00348-01} {AI05-0183-1} null_procedure_declaration ::= 
           [overriding_indicator]
           procedure_specification is null
               [aspect_specification];


                               Legality Rules

2.1/3 {AI05-0177-1} 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 {AI95-00348-01} {AI05-0177-1} {AI05-0264-1} 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.

3.a/2       Reason: There are no null functions because the return value has
            to be constructed somehow; a function that always raises
            Program_Error doesn't seem very useful or worth the complication.


                              Dynamic Semantics

4/2 {AI95-00348-01} The execution of a null procedure is invoked by a
subprogram call. For the execution of a subprogram call on a null procedure,
the execution of the subprogram_body has no effect.

4.a/2       Ramification: Thus, a null procedure is equivalent to the body

4.b/2           begin
                   null;
                end;

4.c/2       with the exception that a null procedure can be used in place of a
            procedure specification.

5/3 {AI95-00348-01} {AI05-0177-1} 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     {AI95-00433-01}
        procedure Simplify(Expr : in out Expression) is null; -- see 3.9
        -- By default, Simplify does nothing, but it may be overridden in extensions of Expression


                            Extensions to Ada 95

6.a/2       {AI95-00348-01} Null procedures are new.


                           Extensions to Ada 2005

6.b/3       {AI05-0177-1} A null_procedure_declaration can now be a completion.

6.c/3       {AI05-0183-1} An optional aspect_specification can be used in a
            null_procedure_declaration. This is described in 13.1.1.


6.8 Expression Functions


1/3 {AI05-0177-1} An expression_function_declaration provides a shorthand to
declare a function whose body consists of a single return statement.


                                   Syntax

2/4     {AI95-0177-1} {AI95-0147-1} expression_function_declaration ::= 
           [overriding_indicator]
           function_specification is
               (expression)
               [aspect_specification];
         | [overriding_indicator]
           function_specification is
               aggregate
               [aspect_specification];


                            Name Resolution Rules

3/4 {AI05-0177-1} {AI95-0147-1} The expected type for the expression or
aggregate of an expression_function_declaration is the result type (see 6.5)
of the function.


                               Legality Rules

4/3 {AI05-0177-1} 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 {AI05-0177-1} {AI95-0147-1} 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.a/3       Ramification: This can only fail if the discriminant is an access
            to a part of a non-aliased parameter, as there can be no local
            declarations here.

5.b/4       Discussion: {AI12-0005-1} We don't need to repeat any of the other
            Legality Rules for return statements since none of them can fail
            here: the implicit return statement has to apply to this function
            (and isn't nested in something), there clearly is a return
            statement in this function, and the static class-wide
            accessibility check cannot fail as a tagged type cannot be
            declared locally in an expression function.


                              Static Semantics

6/4 {AI05-0177-1} {AI05-0264-1} {AI95-0147-1} 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.


                              Dynamic Semantics

7/4 {AI05-0177-1} {AI05-0262-1} {AI95-0147-1} 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.

7.a/3       Discussion: The last sentence effectively means that all of the
            dynamic wording in 6.5 applies as needed, and we don't have to
            repeat it here.

8/3 {AI05-0177-1} 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     {AI05-0177-1}
        function Is_Origin (P : in Point) return Boolean is -- see 3.9
           (P.X = 0.0 and P.Y = 0.0);


                           Extensions to Ada 2005

9.a/3       {AI05-0177-1} Expression functions are new in Ada 2012.


                           Extensions to Ada 2012

9.b/4       {AI12-0157-1} A aggregate can directly be the return expression of
            an expression function. This eliminates the double parentheses
            that otherwise would be necessary.

Generated by dwww version 1.15 on Sun Jun 16 17:23:04 CEST 2024.