Section 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 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/2 subprogram_declaration ::= [overriding_indicator] subprogram_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/2 The sequence of characters in an operator_symbol shall form a reserved word, a delimiter, or compound delimiter that corresponds to an operator belonging to one of the six categories of operators defined in clause 4.5. 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/2 parameter_specification ::= defining_identifier_list : mode [null_exclusion] subtype_mark [:= default_expression] | defining_identifier_list : access_definition [:= default_expression] 16 mode ::= [in] | in out | out Name Resolution Rules 17 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 The parameter mode of a formal parameter conveys the direction of information transfer with the actual parameter: in, in out, or out. Mode in is the default, and is the mode of a parameter defined by an access_definition. The formal parameters of a function, if any, shall have the mode in. 19 A default_expression is only allowed in a parameter_specification for a formal parameter of mode in. 20/2 A subprogram_declaration or a generic_subprogram_declaration requires a completion: a body, a renaming_declaration (see 8.5), or a pragma Import (see B.1). A completion is not allowed for an abstract_subprogram_declaration (see 3.9.3) or a null_procedure_declaration (see 6.7). 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. 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/2 * For any access parameters of an access-to-subprogram type, the subtypes of the 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/2 * For any access result type of an access-to-subprogram type, the subtypes of the profile of the result type. 29 The types of a profile are the types of those subtypes. 30/2 A subprogram declared by an abstract_subprogram_declaration is abstract; a subprogram declared by a subprogram_declaration is not. See 3.9.3, " Abstract Types and Subprograms". Similarly, a procedure defined by a null_procedure_declaration is a null procedure; a procedure declared by a subprogram_declaration is not. See 6.7, "Null Procedures". 30.1/2 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 function Min_Cell(X : Link) return Cell; -- see 3.10.1 function Next_Frame(K : Positive) return Frame; -- see 3.10 function Dot_Product(Left, Right : Vector) return Real; -- see 3.6 40 function "*"(Left, Right : Matrix) return Matrix; -- see 3.6 41 Examples of in parameters with default expressions: 42 procedure Print_Header(Pages : in Natural; Header : in Line := (1 .. Line'Last => ' '); -- see 3.6 Center : in Boolean := True); 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 A type is a by-copy type if it is an elementary type, or if it is a descendant of a private type whose full type is a by-copy type. A parameter of a by-copy type is passed by copy. 4 A type is a by-reference type if it is a descendant of one of the following: 5 * a tagged type; 6 * a task or protected type; 7 * a nonprivate type with the reserved word limited in its declaration; 8 * a composite type with a subcomponent of a by-reference type; 9 * a private type whose full type is a by-reference type. 10 A parameter of a by-reference type is passed by reference. Each value of a by-reference type has an associated object. For a parenthesized expression, qualified_expression, or type_conversion, this object is the one associated with the operand. 11 For parameters of other types, it is unspecified whether the parameter is passed by copy or by reference. Bounded (Run-Time) Errors 12 If one name denotes a part of a formal parameter, and a second name denotes a part of a distinct formal parameter or an object that is not part of a formal parameter, then the two names are considered distinct access paths. If an object is of a type for which the parameter passing mechanism is not specified, then it is a bounded error to assign to the object via one access path, and then read the value of the object via a distinct access path, unless the first access path denotes a part of a formal parameter that no longer exists at the point of the second access (due to leaving the corresponding callable construct). 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 5 A formal parameter of mode in is a constant view (see 3.3); it cannot be updated within the subprogram_body. 6.3 Subprogram Bodies 1 A subprogram_body specifies the execution of a subprogram. Syntax 2/2 subprogram_body ::= [overriding_indicator] subprogram_specification is declarative_part begin handled_sequence_of_statements end [designator]; 3 If a designator appears at the end of a subprogram_body, it shall repeat the defining_designator of the subprogram_specification. Legality Rules 4 In contrast to other bodies, a subprogram_body need not be the completion of a previous declaration, in which case the body declares the subprogram. If the body is a completion, it shall be the completion of a subprogram_declaration or generic_subprogram_declaration. The profile of a subprogram_body that completes a declaration shall conform fully to that of the declaration. 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 non-generic subprogram_body has no other effect than to establish that the subprogram can from then on be called without failing the Elaboration_Check. 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 Pragmas", a convention can be specified for an entity. Unless this International Standard states otherwise, the default convention of an entity is Ada. For a callable entity or access-to-subprogram type, the convention is called the calling convention. The following conventions are defined by the language: 3 * The default calling convention for any subprogram not listed below is Ada. A pragma Convention, Import, or Export may be used to override the default calling convention (see B.1). 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/2 * any prefixed view of a subprogram (see 4.1.3). 11 The Access attribute is not allowed for Intrinsic subprograms. 12 * The default calling convention is protected for a protected subprogram, and for an access-to-subprogram type with the reserved word protected in its definition. 13 * The default calling convention is entry for an entry. 13.1/2 * The calling convention for an anonymous access-to-subprogram parameter or anonymous access-to-subprogram result is protected if the reserved word protected appears in its definition and otherwise is the convention of the subprogram that contains the parameter. 13.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 Of these four conventions, only Ada and Intrinsic are allowed as a convention_identifier in a pragma Convention, Import, or Export. 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/2 Two profiles are mode conformant if they are type-conformant, and corresponding parameters have identical modes, and, for access parameters or access result types, the designated subtypes statically match, or the designated profiles are subtype conformant. 17 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 Two profiles are fully conformant if they are subtype-conformant, and corresponding parameters have the same names and have default_expressions that are fully conformant with one another. 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 21 * each direct_name, character_literal, and selector_name that is not part of the prefix of an expanded name in one denotes the same declaration as the corresponding direct_name, character_literal, or selector_name in the other; and 21.1/1 * each attribute_designator in one must be the same as the corresponding attribute_designator in the other; and 22 * each primary that is a literal in one has the same value as the corresponding literal in the other. 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. Syntax 2 The form of a pragma Inline, which is a program unit pragma (see 10.1.5), is as follows: 3 pragma Inline(name {, name}); Legality Rules 4 The pragma shall apply to one or more callable entities or generic subprograms. Static Semantics 5 If a pragma Inline applies to a callable entity, this indicates that inline expansion is desired for all calls to that entity. If a pragma Inline applies to a generic subprogram, this indicates that inline expansion is desired for all calls to all instances of that generic subprogram. Implementation Permissions 6 For each call, an implementation is free to follow or to ignore the recommendation expressed by the pragma. 6.1/2 An implementation may allow a pragma Inline that has an argument which is a direct_name denoting a subprogram_body of the same declarative_part. NOTES 7 6 The name in a pragma Inline can denote more than one entity in the case of overloading. Such a pragma applies to all of the denoted entities. 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 procedure Pair(Left, Right : in Person_Name := new Person); -- see 3.10.1 21 Examples of their calls: 22 Activate(X); Activate(X, After => Y); Activate(X, Wait => 60.0, Prior => True); Activate(X, Y, 10.0, False); 23 Pair; Pair(Left => new Person, Right => new Person); NOTES 24 7 If a default_expression is used for two or more parameters in a multiple parameter_specification, the default_expression is evaluated once for each omitted parameter. Hence in the above examples, the two calls of Pair are equivalent. Examples 25 Examples of overloaded subprograms: 26 procedure Put(X : in Integer); procedure Put(X : in String); 27 procedure Set(Tint : in Color); procedure Set(Signal : in Light); 28 Examples of their calls: 29 Put(28); Put("no possible ambiguity here"); 30 Set(Tint => Red); Set(Signal => Red); Set(Color'(Red)); 31 -- Set(Red) would be ambiguous since Red may -- denote a value either of type Color or of type Light 6.4.1 Parameter Associations 1 A parameter association defines the association between an actual parameter and a formal parameter. Name Resolution Rules 2 The formal_parameter_selector_name of a parameter_association shall resolve to denote a parameter_specification of the view being called. 3 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. 6 The type of the actual parameter associated with an access parameter shall be convertible (see 4.6) to its anonymous access type. 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 * For an access type, the formal parameter is initialized from the value of the actual, without a constraint check; 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. 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. 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/2 extended_return_statement ::= return defining_identifier : [aliased] return_subtype_indication [:= expression] [do handled_sequence_of_statements end return]; 2.2/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/2 A function body shall contain at least one return statement that applies to the function body, unless the function contains code_statements. A simple_- return_statement shall include an expression if and only if it applies to a function body. An extended_return_statement shall apply to a function body. 5.1/2 For an extended_return_statement that applies to a function body: 5.2/2 * If the result subtype of the function is defined by a subtype_mark, the return_subtype_indication shall be a subtype_indication. The type of the subtype_indication shall be the result type of the function. If the result subtype of the function is constrained, then the subtype defined by the subtype_indication shall also be constrained and shall statically match this result subtype. If the result subtype of the function is unconstrained, then the subtype defined by the subtype_indication shall be a definite subtype, or there shall be an expression. 5.3/2 * If the result subtype of the function is defined by an access_definition, the return_subtype_indication shall be an access_definition. The subtype defined by the access_definition shall statically match the result subtype of the function. The accessibility level of this anonymous access subtype is that of the result subtype. 5.4/2 For any return statement that applies to a function body: 5.5/2 * If the result subtype of the function is limited, then the expression of the return statement (if any) shall be an aggregate, a function call (or equivalent use of an operator), or a qualified_expression or parenthesized expression whose operand is one of these. 5.6/2 * If the result subtype of the function is class-wide, the accessibility level of the type of the expression of the return statement shall not be statically deeper than that of the master that elaborated the function body. If the result subtype has one or more unconstrained access discriminants, the accessibility level of the anonymous access type of each access discriminant, as determined by the expression of the simple_return_statement or the return_subtype_- indication, shall not be statically deeper than that of the master that elaborated the function body. Static Semantics 5.7/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. Dynamic Semantics 5.8/2 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. 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/2 If the result type of a function is a specific tagged type, the tag of the return object is that of the result type. If the result type is class-wide, the tag of the return object is that of the value of the expression. A check is made that the accessibility level of the type identified by the tag of the result is not deeper than that of the master that elaborated the function body. If this check fails, Program_Error is raised. Paragraphs 9 through 20 were deleted. 21/2 If the result subtype of a function has one or more unconstrained access discriminants, a check is made that the accessibility level of the anonymous access type of each access discriminant, as determined by the expression or the return_subtype_indication of the function, is not deeper than that of the master that elaborated the function body. If this check fails, Program_Error is raised. 22/2 For the execution of an extended_return_statement, the handled_sequence_- of_statements is executed. Within this handled_sequence_of_statements, the execution of a simple_return_statement that applies to the extended_return_- statement causes a transfer of control that completes the extended_return_- statement. Upon completion of a return statement that applies to a callable construct, a transfer of control is performed which completes the execution of the callable construct, and returns to the caller. 23/2 In the case of a function, the function_call denotes a constant view of the return object. Implementation Permissions 24/2 If the result subtype of a function is unconstrained, and a call on the function is used to provide the initial value of an object with a constrained nominal subtype, Constraint_Error may be raised at the point of the call (after abandoning the execution of the function body) if, while elaborating the return_subtype_indication or evaluating the expression of a return statement that applies to the function body, it is determined that the value of the result will violate the constraint of the subtype of this object. 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 Pragma No_Return 1/2 A pragma No_Return indicates that a procedure cannot return normally; it may propagate an exception or loop forever. Syntax 2/2 The form of a pragma No_Return, which is a representation pragma (see 13.1), is as follows: 3/2 pragma No_Return(procedure_local_name{, procedure_local_name}); Legality Rules 4/2 Each procedure_local_name shall denote one or more procedures or generic procedures; the denoted entities are non-returning. The procedure_local_name shall not denote a null procedure nor an instance of a generic unit. 5/2 A return statement shall not apply to a non-returning procedure or generic procedure. 6/2 A procedure shall be non-returning if it overrides a dispatching non-returning 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 non-returning procedure declaration, then the renamed procedure shall be non-returning. Static Semantics 8/2 If a generic procedure is non-returning, then so are its instances. If a procedure declared within a generic unit is non-returning, then so are the corresponding copies of that procedure in instances. Dynamic Semantics 9/2 If the body of a non-returning procedure completes normally, Program_Error is raised at the point of the call. Examples 10/2 procedure Fail(Msg : String); -- raises Fatal_Error exception pragma No_Return(Fail); -- 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 The subprogram_specification of a unary or binary operator shall have one or two parameters, respectively. A generic function instantiation whose designator is an operator_symbol is only allowed if the specification of the generic function has the corresponding number of parameters. 4 Default_expressions are not allowed for the parameters of an operator (whether the operator is declared with an explicit subprogram_specification or by a generic_instantiation). 5 An explicit declaration of "/=" shall not have a result type of the predefined type Boolean. Static Semantics 6 A declaration of "=" whose result type is Boolean implicitly declares a declaration of "/=" that gives the complementary result. NOTES 7 8 The operators "+" and "-" are both unary and binary operators, and hence may be overloaded with both one- and two-parameter functions. Examples 8 Examples of user-defined operators: 9 function "+" (Left, Right : Matrix) return Matrix; function "+" (Left, Right : Vector) return Vector; -- assuming that A, B, and C are of the type Vector -- the following two statements are equivalent: A := B + C; A := "+"(B, C); 6.7 Null Procedures 1/2 A null_procedure_declaration provides a shorthand to declare a procedure with an empty body. Syntax 2/2 null_procedure_declaration ::= [overriding_indicator] procedure_specification is null; Static Semantics 3/2 A null_procedure_declaration declares a null procedure. A completion is not allowed for a null_procedure_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/2 The elaboration of a null_procedure_declaration has no effect. 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