6 Subprograms 1 A subprogram is a program unit or intrinsic operation whose execution is invoked by a subprogram call. There are two forms of subprogram: procedures and functions. A procedure call is a statement; a function call is an expression and returns a value. The definition of a subprogram can be given in two parts: a subprogram declaration defining its interface, and a subprogram_body defining its execution. Operators and enumeration literals are functions. 2/3 A callable entity is a subprogram or entry (see Section 9). A callable entity is invoked by a call; that is, a subprogram call or entry call. A callable construct is a construct that defines the action of a call upon a callable entity: a subprogram_body, entry_body, or accept_statement. 6.1 Subprogram Declarations 1 A subprogram_declaration declares a procedure or function. Syntax 2/3 subprogram_declaration ::= [overriding_indicator] subprogram_specification [aspect_specification]; 3/2 This paragraph was deleted. 4/2 subprogram_specification ::= procedure_specification | function_specification 4.1/2 procedure_specification ::= procedure defining_program_unit_name parameter_profile 4.2/2 function_specification ::= function defining_designator parameter_and_result_profile 5 designator ::= [parent_unit_name . ]identifier | operator_symbol 6 defining_designator ::= defining_program_unit_name | defining_operator_symbol 7 defining_program_unit_name ::= [parent_unit_name . ]defining_identifier 8 The optional parent_unit_name is only allowed for library units (see 10.1.1). 9 operator_symbol ::= string_literal 10/3 The sequence of characters in an operator_symbol shall form a reserved word, a delimiter, or compound delimiter that corresponds to an operator belonging to one of the six categories of operators defined in subclause 4.5. 11 defining_operator_symbol ::= operator_symbol 12 parameter_profile ::= [formal_part] 13/2 parameter_and_result_profile ::= [formal_part] return [null_exclusion] subtype_mark | [formal_part] return access_definition 14 formal_part ::= (parameter_specification {; parameter_specification}) 15/3 parameter_specification ::= defining_identifier_list : [aliased] mode [null_exclusion ] subtype_mark [:= default_expression] | defining_identifier_list : access_definition [:= default_expression] 16 mode ::= [in] | in out | out Name Resolution Rules 17 A formal parameter is an object directly visible within a subprogram_body that represents the actual parameter passed to the subprogram in a call; it is declared by a parameter_specification. For a formal parameter, the expected type for its default_expression, if any, is that of the formal parameter. Legality Rules 18/3 The parameter mode of a formal parameter conveys the direction of information transfer with the actual parameter: in, in out, or out. Mode in is the default, and is the mode of a parameter defined by an access_definition. 19 A default_expression is only allowed in a parameter_specification for a formal parameter of mode in. 20/3 A subprogram_declaration or a generic_subprogram_declaration requires a completion unless the Import aspect (see B.1) is True for the declaration; the completion shall be a body or a renaming_declaration (see 8.5). A completion is not allowed for an abstract_subprogram_declaration (see 3.9.3), a null_procedure_declaration (see 6.7), or an expression_function_declaration (see 6.8). 21 A name that denotes a formal parameter is not allowed within the formal_part in which it is declared, nor within the formal_part of a corresponding body or accept_statement. Static Semantics 22 The profile of (a view of) a callable entity is either a parameter_profile or parameter_and_result_profile; it embodies information about the interface to that entity - for example, the profile includes information about parameters passed to the callable entity. All callable entities have a profile - enumeration literals, other subprograms, and entries. An access-to-subprogram type has a designated profile. Associated with a profile is a calling convention. A subprogram_declaration declares a procedure or a function, as indicated by the initial reserved word, with name and profile as given by its specification. 23/2 The nominal subtype of a formal parameter is the subtype determined by the optional null_exclusion and the subtype_mark, or defined by the access_definition, in the parameter_specification. The nominal subtype of a function result is the subtype determined by the optional null_exclusion and the subtype_mark, or defined by the access_definition, in the parameter_and_result_profile. 23.1/3 An explicitly aliased parameter is a formal parameter whose parameter_specification includes the reserved word aliased. 24/2 An access parameter is a formal in parameter specified by an access_definition. An access result type is a function result type specified by an access_definition. An access parameter or result type is of an anonymous access type (see 3.10). Access parameters of an access-to-object type allow dispatching calls to be controlled by access values. Access parameters of an access-to-subprogram type permit calls to subprograms passed as parameters irrespective of their accessibility level. 25 The subtypes of a profile are: 26 * For any non-access parameters, the nominal subtype of the parameter. 27/2 * For any access parameters of an access-to-object type, the designated subtype of the parameter type. 27.1/3 * For any access parameters of an access-to-subprogram type, the subtypes of the designated profile of the parameter type. 28/2 * For any non-access result, the nominal subtype of the function result. 28.1/2 * For any access result type of an access-to-object type, the designated subtype of the result type. 28.2/3 * For any access result type of an access-to-subprogram type, the subtypes of the designated profile of the result type. 29 The types of a profile are the types of those subtypes. 30/3 A subprogram declared by an abstract_subprogram_declaration is abstract; a subprogram declared by a subprogram_declaration is not. See 3.9.3, " Abstract Types and Subprograms". Similarly, a procedure declared by a null_procedure_declaration is a null procedure; a procedure declared by a subprogram_declaration is not. See 6.7, "Null Procedures". Finally, a function declared by an expression_function_declaration is an expression function; a function declared by a subprogram_declaration is not. See 6.8, " Expression Functions". 30.1/2 An overriding_indicator is used to indicate whether overriding is intended. See 8.3.1, "Overriding Indicators". Dynamic Semantics 31/2 The elaboration of a subprogram_declaration has no effect. NOTES 32 1 A parameter_specification with several identifiers is equivalent to a sequence of single parameter_specifications, as explained in 3.3. 33 2 Abstract subprograms do not have bodies, and cannot be used in a nondispatching call (see 3.9.3, "Abstract Types and Subprograms"). 34 3 The evaluation of default_expressions is caused by certain calls, as described in 6.4.1. They are not evaluated during the elaboration of the subprogram declaration. 35 4 Subprograms can be called recursively and can be called concurrently from multiple tasks. Examples 36 Examples of subprogram declarations: 37 procedure Traverse_Tree; procedure Increment(X : in out Integer); procedure Right_Indent(Margin : out Line_Size); -- see 3.5.4 procedure Switch(From, To : in out Link); -- see 3.10.1 38 function Random return Probability; -- see 3.5.7 39/4 function Min_Cell(X : Link) return Cell; -- see 3.10.1 function Next_Frame(K : Positive) return Frame; -- see 3.10 function Dot_Product(Left, Right : Vector) return Real; -- see 3.6 function Find(B : aliased in out Barrel; Key : String) return Real; -- see 4.1.5 40 function "*"(Left, Right : Matrix) return Matrix; -- see 3.6 41 Examples of in parameters with default expressions: 42 procedure Print_Header(Pages : in Natural; Header : in Line := (1 .. Line'Last => ' '); -- see 3.6 Center : in Boolean := True); 6.1.1 Preconditions and Postconditions 1/4 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): 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. 3/3 Pre'Class This aspect specifies a class-wide precondition for an operation of a tagged type and its descendants; it shall be specified by an expression, called a class-wide precondition expression. If not specified for an entity, then if no other class-wide precondition applies to the entity, the class-wide precondition expression for the entity is the enumeration literal True. 4/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. 5/3 Post'Class This aspect specifies a class-wide postcondition for an operation of a tagged type and its descendants; it shall be specified by an expression, called a class-wide postcondition expression. If not specified for an entity, the class-wide postcondition expression for the entity is the enumeration literal True. Name Resolution Rules 6/3 The expected type for a precondition or postcondition expression is any boolean type. 7/4 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. 8/3 For an attribute_reference with attribute_designator Old, if the attribute reference has an expected type or shall resolve to a given type, the same applies to the prefix; otherwise, the prefix shall be resolved independently of context. Legality Rules 9/3 The Pre or Post aspect shall not be specified for an abstract subprogram or a null procedure. Only the Pre'Class and Post'Class aspects may be specified for such a subprogram. 10/3 If a type T has an implicitly declared subprogram P inherited from a parent type T1 and a homograph (see 8.3) of P from a progenitor type T2, and 11/3 * the corresponding primitive subprogram P1 of type T1 is neither null nor abstract; and 12/3 * the class-wide precondition expression True does not apply to P1 (implicitly or explicitly); and 13/3 * there is a class-wide precondition expression that applies to the corresponding primitive subprogram P2 of T2 that does not fully conform to any class-wide precondition expression that applies to P1, 14/3 then: 15/3 * If the type T is abstract, the implicitly declared subprogram P is abstract. 16/3 * Otherwise, the subprogram P requires overriding and shall be overridden with a nonabstract subprogram. 17/3 If a renaming of a subprogram or entry S1 overrides an inherited subprogram S2, then the overriding is illegal unless each class-wide precondition expression that applies to S1 fully conforms to some class-wide precondition expression that applies to S2 and each class-wide precondition expression that applies to S2 fully conforms to some class-wide precondition expression that applies to S1. 17.1/4 Pre'Class shall not be specified for an overriding primitive subprogram of a tagged type T unless the Pre'Class aspect is specified for the corresponding primitive subprogram of some ancestor of T. 17.2/4 In addition to the places where Legality Rules normally apply (see 12.3), these rules also apply in the private part of an instance of a generic unit. Static Semantics 18/4 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.1/4 * References to formal parameters of S (or to S itself) are replaced with references to the corresponding formal parameters of the corresponding inherited or overriding subprogram S (or to the corresponding subprogram S itself). 18.2/4 The primitive subprogram S is illegal if it is not abstract and the corresponding expression for a Pre'Class or Post'Class aspect would be illegal. 19/3 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. 20/3 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 * 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 For a prefix X that denotes an object of a nonlimited type, the following attribute is defined: 26/4 X'Old 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 The implicitly declared entity denoted by each occurrence of X'Old is declared as follows: 26.2/4 * If X is of an anonymous access type defined by an access_definition A then 26.3/4 X'Old : constant A := X; 26.4/4 * If X is of a specific tagged type T then 26.5/4 anonymous : constant T'Class := T'Class(X); X'Old : T renames T(anonymous); 26.6/4 where the name X'Old denotes the object renaming. 26.7/4 * Otherwise 26.8/4 X'Old : constant S := X; 26.9/4 where S is the nominal subtype of X. This includes the case where the type of S is an anonymous array type or a universal type. 26.10/4 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 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. 28/3 For a prefix F that denotes a function declaration, the following attribute is defined: 29/3 F'Result 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 Use of this attribute is allowed only within a postcondition expression for F. Dynamic Semantics 31/3 Upon a call of the subprogram or entry, after evaluating any actual parameters, precondition checks are performed as follows: 32/3 * The specific precondition check begins with the evaluation of the specific precondition expression that applies to the subprogram or entry, if it is enabled; if the expression evaluates to False, Assertions.Assertion_Error is raised; if the expression is not enabled, the check succeeds. 33/3 * The class-wide precondition check begins with the evaluation of any enabled class-wide precondition expressions that apply to the subprogram or entry. If and only if all the class-wide precondition expressions evaluate to False, Assertions.Assertion_Error is raised. 34/3 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. 35/3 Upon successful return from a call of the subprogram or entry, prior to copying back any by-copy in out or out parameters, the postcondition check is performed. This consists of the evaluation of any enabled specific and class-wide postcondition expressions that apply to the subprogram or entry. If any of the postcondition expressions evaluate to False, then Assertions.Assertion_Error is raised. The postcondition expressions are evaluated in an arbitrary order, and if any postcondition expression evaluates to False, it is not specified whether any other postcondition expressions are evaluated. The postcondition check, and any constraint or predicate checks associated with in out or out parameters are performed in an arbitrary order. 35.1/4 For a call to a task entry, the postcondition check is performed before the end of the rendezvous; for a call to a protected operation, the postcondition check is performed before the end of the protected action of the call. The postcondition check for any call is performed before the finalization of any implicitly-declared constants associated (as described above) with Old attribute_references but after the finalization of any other entities whose accessibility level is that of the execution of the callable construct. 36/3 If a precondition or postcondition check fails, the exception is raised at the point of the call; the exception cannot be handled inside the called subprogram or entry. Similarly, any exception raised by the evaluation of a precondition or postcondition expression is raised at the point of call. 37/4 For any call to a subprogram or entry S (including dispatching calls), the checks that are performed to verify specific precondition expressions and specific and class-wide postcondition expressions are determined by those for the subprogram or entry actually invoked. Note that the class-wide postcondition expressions verified by the postcondition check that is part of a call on a primitive subprogram of type T includes all class-wide postcondition expressions originating in any progenitor of T, even if the primitive subprogram called is inherited from a type T1 and some of the postcondition expressions do not apply to the corresponding primitive subprogram of T1. Any operations within a class-wide postcondition expression that were resolved as primitive operations of the (notional) formal derived type NT, are in the evaluation of the postcondition bound to the corresponding operations of the type identified by the controlling tag of the call on S. This applies to both dispatching and non-dispatching calls on S. 38/4 The class-wide precondition check for a call to a subprogram or entry S consists solely of checking the class-wide precondition expressions that apply to the denoted callable entity (not necessarily to the one that is invoked). Any operations within such an expression that were resolved as primitive operations of the (notional) formal derived type NT are in the evaluation of the precondition bound to the corresponding operations of the type identified by the controlling tag of the call on S. This applies to both dispatching and non-dispatching calls on S. 39/3 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 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. 6.2 Formal Parameter Modes 1 A parameter_specification declares a formal parameter of mode in, in out, or out. Static Semantics 2 A parameter is passed either by copy or by reference. When a parameter is passed by copy, the formal parameter denotes a separate object from the actual parameter, and any information transfer between the two occurs only before and after executing the subprogram. When a parameter is passed by reference, the formal parameter denotes (a view of) the object denoted by the actual parameter; reads and updates of the formal parameter directly reference the actual parameter object. 3/3 A type is a by-copy type if it is an elementary type, or if it is a descendant of a private type whose full type is a by-copy type. A parameter of a by-copy type is passed by copy, unless the formal parameter is explicitly aliased. 4 A type is a by-reference type if it is a descendant of one of the following: 5 * a tagged type; 6 * a task or protected type; 7/3 * an explicitly limited record type; 8 * a composite type with a subcomponent of a by-reference type; 9 * a private type whose full type is a by-reference type. 10/4 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. 11/3 For other parameters, it is unspecified whether the parameter is passed by copy or by reference. Bounded (Run-Time) Errors 12/3 If one name denotes a part of a formal parameter, and a second name denotes a part of a distinct formal parameter or an object that is not part of a formal parameter, then the two names are considered distinct access paths. If an object is of a type for which the parameter passing mechanism is not specified and is not an explicitly aliased parameter, then it is a bounded error to assign to the object via one access path, and then read the value of the object via a distinct access path, unless the first access path denotes a part of a formal parameter that no longer exists at the point of the second access (due to leaving the corresponding callable construct). The possible consequences are that Program_Error is raised, or the newly assigned value is read, or some old value of the object is read. NOTES 13/4 6 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 A formal parameter of mode out might be uninitialized at the start of the subprogram_body (see 6.4.1). 6.3 Subprogram Bodies 1 A subprogram_body specifies the execution of a subprogram. Syntax 2/3 subprogram_body ::= [overriding_indicator] subprogram_specification [aspect_specification] is declarative_part begin handled_sequence_of_statements end [designator]; 3 If a designator appears at the end of a subprogram_body, it shall repeat the defining_designator of the subprogram_specification. Legality Rules 4 In contrast to other bodies, a subprogram_body need not be the completion of a previous declaration, in which case the body declares the subprogram. If the body is a completion, it shall be the completion of a subprogram_declaration or generic_subprogram_declaration. The profile of a subprogram_body that completes a declaration shall conform fully to that of the declaration. Static Semantics 5 A subprogram_body is considered a declaration. It can either complete a previous declaration, or itself be the initial declaration of the subprogram. Dynamic Semantics 6 The elaboration of a nongeneric subprogram_body has no other effect than to establish that the subprogram can from then on be called without failing the Elaboration_Check. 7 The execution of a subprogram_body is invoked by a subprogram call. For this execution the declarative_part is elaborated, and the handled_sequence_of_statements is then executed. Examples 8 Example of procedure body: 9 procedure Push(E : in Element_Type; S : in out Stack) is begin if S.Index = S.Size then raise Stack_Overflow; else S.Index := S.Index + 1; S.Space(S.Index) := E; end if; end Push; 10 Example of a function body: 11 function Dot_Product(Left, Right : Vector) return Real is Sum : Real := 0.0; begin Check(Left'First = Right'First and Left'Last = Right'Last); for J in Left'Range loop Sum := Sum + Left(J)*Right(J); end loop; return Sum; end Dot_Product; 6.3.1 Conformance Rules 1 When subprogram profiles are given in more than one place, they are required to conform in one of four ways: type conformance, mode conformance, subtype conformance, or full conformance. Static Semantics 2/1 As explained in B.1, "Interfacing Aspects", a convention can be specified for an entity. Unless this International Standard states otherwise, the default convention of an entity is Ada. For a callable entity or access-to-subprogram type, the convention is called the calling convention. The following conventions are defined by the language: 3/3 * The default calling convention for any subprogram not listed below is Ada. The Convention aspect may be specified to override the default calling convention (see B.1). 4 * The Intrinsic calling convention represents subprograms that are " built in" to the compiler. The default calling convention is Intrinsic for the following: 5 * an enumeration literal; 6 * a "/=" operator declared implicitly due to the declaration of "=" (see 6.6); 7 * any other implicitly declared subprogram unless it is a dispatching operation of a tagged type; 8 * an inherited subprogram of a generic formal tagged type with unknown discriminants; 9 * an attribute that is a subprogram; 10/2 * a subprogram declared immediately within a protected_body; 10.1/4 * any prefixed view of a subprogram (see 4.1.3) without synchronization kind (see 9.5) By_Entry or By_Protected_Procedure. 11 The Access attribute is not allowed for Intrinsic subprograms. 12/4 * The default calling convention is protected for a protected subprogram, for a prefixed view of a subprogram with a synchronization kind of By_Protected_Procedure, and for an access-to-subprogram type with the reserved word protected in its definition. 13/4 * The default calling convention is entry for an entry and for a prefixed view of a subprogram with a synchronization kind of By_Entry. 13.1/3 * 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.2/1 * If not specified above as Intrinsic, the calling convention for any inherited or overriding dispatching operation of a tagged type is that of the corresponding subprogram of the parent type. The default calling convention for a new dispatching operation of a tagged type is the convention of the type. 14/3 Of these four conventions, only Ada and Intrinsic are allowed as a convention_identifier in the specification of a Convention aspect. 15/2 Two profiles are type conformant if they have the same number of parameters, and both have a result if either does, and corresponding parameter and result types are the same, or, for access parameters or access results, corresponding designated types are the same, or corresponding designated profiles are type conformant. 16/3 Two profiles are mode conformant if: 16.1/3 * they are type conformant; and 16.2/3 * corresponding parameters have identical modes and both or neither are explicitly aliased parameters; and 16.3/3 * for corresponding access parameters and any access result type, the designated subtypes statically match and either both or neither are access-to-constant, or the designated profiles are subtype conformant. 17/3 Two profiles are subtype conformant if they are mode conformant, corresponding subtypes of the profile statically match, and the associated calling conventions are the same. The profile of a generic formal subprogram is not subtype conformant with any other profile. 18/3 Two profiles are fully conformant if they are subtype conformant, if they have access-to-subprogram results whose designated profiles are fully conformant, and for corresponding parameters: 18.1/3 * they have the same names; and 18.2/3 * both or neither have null_exclusions; and 18.3/3 * neither have default_expressions, or they both have default_expressions that are fully conformant with one another; and 18.4/3 * for access-to-subprogram parameters, the designated profiles are fully conformant. 19 Two expressions are fully conformant if, after replacing each use of an operator with the equivalent function_call: 20 * each constituent construct of one corresponds to an instance of the same syntactic category in the other, except that an expanded name may correspond to a direct_name (or character_literal) or to a different expanded name in the other; and 20.1/4 * corresponding defining_identifiers occurring within the two expressions are the same; and 21/4 * each direct_name, character_literal, and selector_name that is not part of the prefix of an expanded name in one denotes the same declaration as the corresponding direct_name, character_literal, or selector_name in the other, or they denote corresponding declarations occurring within the two expressions; and 21.1/3 * each attribute_designator in one is the same as the corresponding attribute_designator in the other; and 22 * each primary that is a literal in one has the same value as the corresponding literal in the other. 23 Two known_discriminant_parts are fully conformant if they have the same number of discriminants, and discriminants in the same positions have the same names, statically matching subtypes, and default_expressions that are fully conformant with one another. 24 Two discrete_subtype_definitions are fully conformant if they are both subtype_indications or are both ranges, the subtype_marks (if any) denote the same subtype, and the corresponding simple_expressions of the ranges (if any) fully conform. 24.1/2 The prefixed view profile of a subprogram is the profile obtained by omitting the first parameter of that subprogram. There is no prefixed view profile for a parameterless subprogram. For the purposes of defining subtype and mode conformance, the convention of a prefixed view profile is considered to match that of either an entry or a protected operation. Implementation Permissions 25 An implementation may declare an operator declared in a language-defined library unit to be intrinsic. 6.3.2 Inline Expansion of Subprograms 1 Subprograms may be expanded in line at the call site. Paragraphs 2 through 4 were moved to Annex J, "Obsolescent Features". Static Semantics 5/3 For a callable entity or a generic subprogram, the following language-defined representation aspect may be specified: 5.1/3 Inline The type of aspect Inline is Boolean. When aspect Inline is True for a callable entity, inline expansion is desired for all calls to that entity. When aspect Inline is True for a generic subprogram, inline expansion is desired for all calls to all instances of that generic subprogram. 5.2/3 If directly specified, the aspect_definition shall be a static expression. This aspect is never inherited; if not directly specified, the aspect is False. Implementation Permissions 6/3 For each call, an implementation is free to follow or to ignore the recommendation determined by the Inline aspect. 6.4 Subprogram Calls 1 A subprogram call is either a procedure_call_statement or a function_call; it invokes the execution of the subprogram_body. The call specifies the association of the actual parameters, if any, with formal parameters of the subprogram. Syntax 2 procedure_call_statement ::= procedure_name; | procedure_prefix actual_parameter_part; 3 function_call ::= function_name | function_prefix actual_parameter_part 4 actual_parameter_part ::= (parameter_association {, parameter_association}) 5 parameter_association ::= [formal_parameter_selector_name =>] explicit_actual_parameter 6 explicit_actual_parameter ::= expression | variable_name 7 A parameter_association is named or positional according to whether or not the formal_parameter_selector_name is specified. Any positional associations shall precede any named associations. Named associations are not allowed if the prefix in a subprogram call is an attribute_- reference. Name Resolution Rules 8/2 The name or prefix given in a procedure_call_statement shall resolve to denote a callable entity that is a procedure, or an entry renamed as (viewed as) a procedure. The name or prefix given in a function_call shall resolve to denote a callable entity that is a function. The name or prefix shall not resolve to denote an abstract subprogram unless it is also a dispatching subprogram. When there is an actual_parameter_part, the prefix can be an implicit_dereference of an access-to-subprogram value. 9 A subprogram call shall contain at most one association for each formal parameter. Each formal parameter without an association shall have a default_expression (in the profile of the view denoted by the name or prefix ). This rule is an overloading rule (see 8.6). Dynamic Semantics 10/2 For the execution of a subprogram call, the name or prefix of the call is evaluated, and each parameter_association is evaluated (see 6.4.1). If a default_expression is used, an implicit parameter_association is assumed for this rule. These evaluations are done in an arbitrary order. The subprogram_- body is then executed, or a call on an entry or protected subprogram is performed (see 3.9.2). Finally, if the subprogram completes normally, then after it is left, any necessary assigning back of formal to actual parameters occurs (see 6.4.1). 10.1/2 If the name or prefix of a subprogram call denotes a prefixed view (see 4.1.3), the subprogram call is equivalent to a call on the underlying subprogram, with the first actual parameter being provided by the prefix of the prefixed view (or the Access attribute of this prefix if the first formal parameter is an access parameter), and the remaining actual parameters given by the actual_parameter_part, if any. 11/2 The exception Program_Error is raised at the point of a function_call if the function completes normally without executing a return statement. 12/2 A function_call denotes a constant, as defined in 6.5; the nominal subtype of the constant is given by the nominal subtype of the function result. Examples 13 Examples of procedure calls: 14 Traverse_Tree; -- see 6.1 Print_Header(128, Title, True); -- see 6.1 15 Switch(From => X, To => Next); -- see 6.1 Print_Header(128, Header => Title, Center => True); -- see 6.1 Print_Header(Header => Title, Center => True, Pages => 128); -- see 6.1 16 Examples of function calls: 17 Dot_Product(U, V) -- see 6.1 and 6.3 Clock -- see 9.6 F.all -- presuming F is of an access-to-subprogram type - see 3.10 18 Examples of procedures with default expressions: 19 procedure Activate(Process : in Process_Name; After : in Process_Name := No_Process; Wait : in Duration := 0.0; Prior : in Boolean := False); 20/3 procedure Pair(Left, Right : in Person_Name := new Person(M)); -- see 3.10.1 21 Examples of their calls: 22 Activate(X); Activate(X, After => Y); Activate(X, Wait => 60.0, Prior => True); Activate(X, Y, 10.0, False); 23/3 Pair; Pair(Left => new Person(F), Right => new Person(M)); NOTES 24 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 6.4.1 Parameter Associations 1 A parameter association defines the association between an actual parameter and a formal parameter. Name Resolution Rules 2/3 The formal_parameter_selector_name of a named parameter_association shall resolve to denote a parameter_specification of the view being called; this is the formal parameter of the association. The formal parameter for a positional parameter_association is the parameter with the corresponding position in the formal part of the view being called. 3 The actual parameter is either the explicit_actual_parameter given in a parameter_association for a given formal parameter, or the corresponding default_expression if no parameter_association is given for the formal parameter. The expected type for an actual parameter is the type of the corresponding formal parameter. 4 If the mode is in, the actual is interpreted as an expression; otherwise, the actual is interpreted only as a name, if possible. Legality Rules 5 If the mode is in out or out, the actual shall be a name that denotes a variable. 5.1/4 If the mode is out, the actual parameter is a view conversion, and the type of the formal parameter is an access type or a scalar type that has the Default_Value aspect specified, then 5.2/4 * there shall exist a type (other than a root numeric type) that is an ancestor of both the target type and the operand type; and 5.3/4 * in the case of a scalar type, the type of the operand of the conversion shall have the Default_Value aspect specified. 5.4/4 In addition to the places where Legality Rules normally apply (see 12.3), these rules also apply in the private part of an instance of a generic unit. 6/3 If the formal parameter is an explicitly aliased parameter, the type of the actual parameter shall be tagged or the actual parameter shall be an aliased view of an object. Further, if the formal parameter subtype F is untagged: 6.1/3 * the subtype F shall statically match the nominal subtype of the actual object; or 6.2/3 * the subtype F shall be unconstrained, discriminated in its full view, and unconstrained in any partial view. 6.3/4 In addition to the places where Legality Rules normally apply (see 12.3), these rules also apply in the private part of an instance of a generic unit. 6.4/3 In a function call, the accessibility level of the actual object for each explicitly aliased parameter shall not be statically deeper than the accessibility level of the master of the call (see 3.10.2). 6.5/3 Two names are known to denote the same object if: 6.6/3 * both names statically denote the same stand-alone object or parameter; or 6.7/3 * both names are selected_components, their prefixes are known to denote the same object, and their selector_names denote the same component; or 6.8/3 * both names are dereferences (implicit or explicit) and the dereferenced names are known to denote the same object; or 6.9/3 * both names are indexed_components, their prefixes are known to denote the same object, and each of the pairs of corresponding index values are either both static expressions with the same static value or both names that are known to denote the same object; or 6.10/3 * both names are slices, their prefixes are known to denote the same object, and the two slices have statically matching index constraints; or 6.11/3 * one of the two names statically denotes a renaming declaration whose renamed object_name is known to denote the same object as the other, the prefix of any dereference within the renamed object_name is not a variable, and any expression within the renamed object_name contains no references to variables nor calls on nonstatic functions. 6.12/3 Two names are known to refer to the same object if 6.13/3 * The two names are known to denote the same object; or 6.14/3 * One of the names is a selected_component, indexed_component, or slice and its prefix is known to refer to the same object as the other name; or 6.15/3 * One of the two names statically denotes a renaming declaration whose renamed object_name is known to refer to the same object as the other name. 6.16/3 If a call C has two or more parameters of mode in out or out that are of an elementary type, then the call is legal only if: 6.17/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.18/3 If a construct C has two or more direct constituents that are names or expressions whose evaluation may occur in an arbitrary order, at least one of which contains a function call with an in out or out parameter, then the construct is legal only if: 6.19/3 * For each name N that is passed as a parameter of mode in out or out to some inner function call C2 (not including the construct C itself), there is no other name anywhere within a direct constituent of the construct C other than the one containing C2, that is known to refer to the same object. 6.20/3 For the purposes of checking this rule: 6.21/3 * For an array aggregate, an expression associated with a discrete_choice_list that has two or more discrete choices, or that has a nonstatic range, is considered as two or more separate occurrences of the expression; 6.22/3 * For a record aggregate: 6.23/3 * The expression of a record_component_association is considered to occur once for each associated component; and 6.24/3 * The default_expression for each record_component_association with <> for which the associated component has a default_expression is considered part of the aggregate; 6.25/3 * For a call, any default_expression evaluated as part of the call is considered part of the call. Dynamic Semantics 7 For the evaluation of a parameter_association: 8 * The actual parameter is first evaluated. 9 * For an access parameter, the access_definition is elaborated, which creates the anonymous access type. 10 * For a parameter (of any mode) that is passed by reference (see 6.2), a view conversion of the actual parameter to the nominal subtype of the formal parameter is evaluated, and the formal parameter denotes that conversion. 11 * For an in or in out parameter that is passed by copy (see 6.2), the formal parameter object is created, and the value of the actual parameter is converted to the nominal subtype of the formal parameter and assigned to the formal. 12 * For an out parameter that is passed by copy, the formal parameter object is created, and: 13/3 * For an access type, the formal parameter is initialized from the value of the actual, without checking that the value satisfies any constraint, any predicate, or any exclusion of the null value; 13.1/4 * For a scalar type that has the Default_Value aspect specified, the formal parameter is initialized from the value of the actual, without checking that the value satisfies any constraint or any predicate. Furthermore, if the actual parameter is a view conversion and either 13.2/4 * there exists no type (other than a root numeric type) that is an ancestor of both the target type and the type of the operand of the conversion; or 13.3/4 * the Default_Value aspect is unspecified for the type of the operand of the conversion 13.4/4 then Program_Error is raised; 14 * 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. 15 * For any other type, the formal parameter is uninitialized. If composite, a view conversion of the actual parameter to the nominal subtype of the formal is evaluated (which might raise Constraint_Error), and the actual subtype of the formal is that of the view conversion. If elementary, the actual subtype of the formal is given by its nominal subtype. 15.1/3 * In a function call, for each explicitly aliased parameter, a check is made that the accessibility level of the master of the actual object is not deeper than that of the master of the call (see 3.10.2 ). 16 A formal parameter of mode in out or out with discriminants is constrained if either its nominal subtype or the actual parameter is constrained. 17 After normal completion and leaving of a subprogram, for each in out or out parameter that is passed by copy, the value of the formal parameter is converted to the subtype of the variable given as the actual parameter and assigned to it. These conversions and assignments occur in an arbitrary order. Erroneous Execution 18/3 If the nominal subtype of a formal parameter with discriminants is constrained or indefinite, and the parameter is passed by reference, then the execution of the call is erroneous if the value of any discriminant of the actual is changed while the formal parameter exists (that is, before leaving the corresponding callable construct). 6.5 Return Statements 1/2 A simple_return_statement or extended_return_statement (collectively called a return statement) is used to complete the execution of the innermost enclosing subprogram_body, entry_body, or accept_statement. Syntax 2/2 simple_return_statement ::= return [expression]; 2.1/3 extended_return_object_declaration ::= defining_identifier : [aliased][constant] return_subtype_indication [:= expression] 2.2/3 extended_return_statement ::= return extended_return_object_declaration [do handled_sequence_of_statements end return]; 2.3/2 return_subtype_indication ::= subtype_indication | access_definition Name Resolution Rules 3/2 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. Legality Rules 4/2 A return statement shall be within a callable construct, and it applies to the innermost callable construct or extended_return_statement that contains it. A return statement shall not be within a body that is within the construct to which the return statement applies. 5/3 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.1/2 For an extended_return_statement that applies to a function body: 5.2/3 * 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 * If the result subtype of the function is defined by an access_definition, the return_subtype_indication shall be an access_definition. The subtype defined by the access_definition shall statically match the result subtype of the function. The accessibility level of this anonymous access subtype is that of the result subtype. 5.4/3 * 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.5/3 For any return statement that applies to a function body: 5.6/3 * 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.7/3 * 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.8/3 * 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.9/3 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 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 For the execution of an extended_return_statement, the subtype_indication or access_definition is elaborated. This creates the nominal subtype of the return object. If there is an expression, it is evaluated and converted to the nominal subtype (which might raise Constraint_Error - see 4.6); the return object is created and the converted value is assigned to the return object. Otherwise, the return object is created and initialized by default as for a stand-alone object of its nominal subtype (see 3.3.1). If the nominal subtype is indefinite, the return object is constrained by its initial value. A check is made that the value of the return object belongs to the function result subtype. Constraint_Error is raised if this check fails. 6/2 For the execution of a simple_return_statement, the expression (if any) is first evaluated, converted to the result subtype, and then is assigned to the anonymous return object. 7/2 If the return object has any parts that are tasks, the activation of those tasks does not occur until after the function returns (see 9.2). 8/4 If the result type of a function is a specific tagged type, the tag of the return object is that of the result type. If the result type is class-wide, the tag of the return object is that of the value of the expression, unless the return object is defined by an extended_return_object_declaration with a subtype_indication that is specific, in which case it is that of the type of the subtype_indication. A check is made that the master of the type identified by the tag of the result includes the elaboration of the master that elaborated the function body. If this check fails, Program_Error is raised. 8.1/3 If the result subtype of the function is defined by an access_definition designating a specific tagged type T, a check is made that the result value is null or the tag of the object designated by the result value identifies T. Constraint_Error is raised if this check fails. Paragraphs 9 through 20 were deleted. 21/3 If any part of the specific type of the return object of a function (or coextension thereof) has one or more access discriminants whose value is not constrained by the result subtype of the function, a check is made that the accessibility level of the anonymous access type of each access discriminant, as determined by the expression or the return_subtype_indication of the return statement, is not deeper than the level of the master of the call (see 3.10.2). If this check fails, Program_Error is raised. 22/3 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. 23/2 In the case of a function, the function_call denotes a constant view of the return object. Implementation Permissions 24/3 For a function call used to initialize a composite object with a constrained nominal subtype or used to initialize a return object that is built in place into such an object: 24.1/3 * If the result subtype of the function is constrained, and conversion of an object of this subtype to the subtype of the object being initialized would raise Constraint_Error, then Constraint_Error may be raised before calling the function. 24.2/3 * If the result subtype of the function is unconstrained, and a return statement is executed such that the return object is known to be constrained, and conversion of the return object to the subtype of the object being initialized would raise Constraint_Error, then Constraint_Error may be raised at the point of the call (after abandoning the execution of the function body). Examples 25 Examples of return statements: 26/2 return; -- in a procedure body, entry_body, -- accept_statement , or extended_return_statement 27 return Key_Value(Last_Index); -- in a function body 28/2 return Node : Cell do -- in a function body, see 3.10.1 for Cell Node.Value := Result; Node.Succ := Next_Node; end return; 6.5.1 Nonreturning Procedures 1/3 Specifying aspect No_Return to have the value True indicates that a procedure cannot return normally; it may propagate an exception or loop forever. Paragraphs 2 and 3 were moved to Annex J, "Obsolescent Features". Static Semantics 3.1/3 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.4/3 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 Aspect No_Return shall not be specified for a null procedure nor an instance of a generic unit. 5/2 A return statement shall not apply to a nonreturning procedure or generic procedure. 6/2 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. 7/2 If a renaming-as-body completes a nonreturning procedure declaration, then the renamed procedure shall be nonreturning. Paragraph 8 was deleted. Dynamic Semantics 9/2 If the body of a nonreturning procedure completes normally, Program_Error is raised at the point of the call. Examples 10/3 procedure Fail(Msg : String) -- raises Fatal_Error exception with No_Return; -- Inform compiler and reader that procedure never returns normally 6.6 Overloading of Operators 1 An operator is a function whose designator is an operator_symbol. Operators, like other functions, may be overloaded. Name Resolution Rules 2 Each use of a unary or binary operator is equivalent to a function_call with function_prefix being the corresponding operator_symbol, and with (respectively) one or two positional actual parameters being the operand(s) of the operator (in order). Legality Rules 3/3 The subprogram_specification of a unary or binary operator shall have one or two parameters, respectively. The parameters shall be of mode in. A generic function instantiation whose designator is an operator_symbol is only allowed if the specification of the generic function has the corresponding number of parameters, and they are all of mode in. 4 Default_expressions are not allowed for the parameters of an operator (whether the operator is declared with an explicit subprogram_specification or by a generic_instantiation). 5 An explicit declaration of "/=" shall not have a result type of the predefined type Boolean. Static Semantics 6/3 An explicit declaration of "=" whose result type is Boolean implicitly declares an operator "/=" that gives the complementary result. NOTES 7 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); 6.7 Null Procedures 1/2 A null_procedure_declaration provides a shorthand to declare a procedure with an empty body. Syntax 2/3 null_procedure_declaration ::= [overriding_indicator] procedure_specification is null [aspect_specification]; Legality Rules 2.1/3 If a null_procedure_declaration is a completion, it shall be the completion of a subprogram_declaration or generic_subprogram_declaration. The profile of a null_procedure_declaration that completes a declaration shall conform fully to that of the declaration. Static Semantics 3/3 A null_procedure_declaration declares a null procedure. A completion is not allowed for a null_procedure_declaration; however, a null_procedure_declaration can complete a previous declaration. Dynamic Semantics 4/2 The execution of a null procedure is invoked by a subprogram call. For the execution of a subprogram call on a null procedure, the execution of the subprogram_body has no effect. 5/3 The elaboration of a null_procedure_declaration has no other effect than to establish that the null procedure can be called without failing the Elaboration_Check. Examples 6/2 procedure Simplify(Expr : in out Expression) is null; -- see 3.9 -- By default, Simplify does nothing, but it may be overridden in extensions of Expression 6.8 Expression Functions 1/3 An expression_function_declaration provides a shorthand to declare a function whose body consists of a single return statement. Syntax 2/4 expression_function_declaration ::= [overriding_indicator] function_specification is (expression) [aspect_specification]; | [overriding_indicator] function_specification is aggregate [aspect_specification]; Name Resolution Rules 3/4 The expected type for the expression or aggregate of an expression_- function_declaration is the result type (see 6.5) of the function. Legality Rules 4/3 If an expression_function_declaration is a completion, it shall be the completion of a subprogram_declaration or generic_subprogram_declaration. The profile of an expression_function_declaration that completes a declaration shall conform fully to that of the declaration. 5/4 If the result subtype has one or more unconstrained access discriminants, the accessibility level of the anonymous access type of each access discriminant, as determined by the expression or aggregate of the expression_- function_declaration, shall not be statically deeper than that of the master that elaborated the expression_function_declaration. Static Semantics 6/4 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 The execution of an expression function is invoked by a subprogram call. For the execution of a subprogram call on an expression function, the execution of the subprogram_body executes an implicit function body containing only a simple_return_statement whose expression is the return expression of the expression function. 8/3 The elaboration of an expression_function_declaration has no other effect than to establish that the expression function can be called without failing the Elaboration_Check. Examples 9/3 function Is_Origin (P : in Point) return Boolean is -- see 3.9 (P.X = 0.0 and P.Y = 0.0);