Section 6: Subprograms 1 {subprogram} {procedure} {function} A subprogram is a program unit or intrinsic operation whose execution is invoked by a subprogram call. There are two forms of subprogram: procedures and functions. A procedure call is a statement; a function call is an expression and returns a value. The definition of a subprogram can be given in two parts: a subprogram declaration defining its interface, and a subprogram_body defining its execution. [Operators and enumeration literals are functions.] 1.a To be honest: A function call is an expression, but more specifically it is a name. 1.b/2 Glossary entry: {Subprogram} A subprogram is a section of a program that can be executed in various contexts. It is invoked by a subprogram call that may qualify the effect of the subprogram through the passing of parameters. There are two forms of subprograms: functions, which return values, and procedures, which do not. 1.c/2 Glossary entry: {Function} A function is a form of subprogram that returns a result and can be called as part of an expression. 1.d/2 Glossary entry: {Procedure} A procedure is a form of subprogram that does not return a result and can only be called by a statement. 2 {callable entity} A callable entity is a subprogram or entry (see Section 9). {call} A callable entity is invoked by a call; that is, a subprogram call or entry call. {callable construct} A callable construct is a construct that defines the action of a call upon a callable entity: a subprogram_body, entry_body, or accept_statement. 2.a Ramification: Note that "callable entity" includes predefined operators, enumeration literals, and abstract subprograms. " Call" includes calls of these things. They do not have callable constructs, since they don't have completions. 6.1 Subprogram Declarations 1 [A subprogram_declaration declares a procedure or function.] Syntax 2/2 {AI95-00218-03} subprogram_declaration ::= [overriding_indicator] subprogram_specification; 3/2 This paragraph was deleted.{AI95-00348-01} 4/2 {AI95-00348-01} subprogram_specification ::= procedure_specification | function_specification 4.1/2 {AI95-00348-01} procedure_specification ::= procedure defining_program_unit_name parameter_profile 4.2/2 {AI95-00348-01} function_specification ::= function defining_designator parameter_and_result_profile 5 designator ::= [parent_unit_name . ]identifier | operator_symbol 6 defining_designator ::= defining_program_unit_name | defining_operator_symbol 7 defining_program_unit_name ::= [parent_unit_name . ]defining_identifier 8 [The optional parent_unit_name is only allowed for library units (see 10.1.1).] 9 operator_symbol ::= string_literal 10/2 {AI95-00395-01} 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. 10.a/2 Reason: {AI95-00395-01} The `sequence of characters" of the string literal of the operator is a technical term (see 2.6), and does not include the surrounding quote characters. As defined in 2.2, lexical elements are "formed" from a sequence of characters. Spaces are not allowed, and upper and lower case is not significant. See 2.2 and 2.9 for rules related to the use of other_format characters in delimiters and reserved words. 11 defining_operator_symbol ::= operator_symbol 12 parameter_profile ::= [formal_part] 13/2 {AI95-00231-01} {AI95-00318-02} parameter_and_result_profile ::= [formal_part] return [null_exclusion] subtype_mark | [formal_part] return access_definition 14 formal_part ::= (parameter_specification {; parameter_specification}) 15/2 {AI95-00231-01} 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 {formal parameter (of a subprogram)} 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. {expected type (parameter default_expression) [partial]} For a formal parameter, the expected type for its default_expression, if any, is that of the formal parameter. {parameter: See formal parameter} Legality Rules 18 {parameter mode} 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. 18.a Ramification: Access parameters are permitted. This restriction to in parameters is primarily a methodological restriction, though it also simplifies implementation for some compiler technologies. 19 A default_expression is only allowed in a parameter_specification for a formal parameter of mode in. 20/2 {AI95-00348-01} {requires a completion (subprogram_declaration) [partial]} {requires a completion (generic_subprogram_declaration) [partial]} 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).] 20.a/2 Ramification: {AI95-00348-01} Abstract subprograms and null procedures are not declared by subprogram_declarations, and so do not require completion. Protected subprograms are declared by subprogram_declarations, and so require completion. Note that an abstract subprogram is a subprogram, and a protected subprogram is a subprogram, but a generic subprogram is not a subprogram. 21 A name that denotes a formal parameter is not allowed within the formal_part in which it is declared, nor within the formal_part of a corresponding body or accept_statement. 21.a Ramification: By contrast, generic_formal_parameter_declarations are visible to subsequent declarations in the same generic_formal_part. Static Semantics 22 {profile} The profile of (a view of) a callable entity is either a parameter_profile or parameter_and_result_profile[; it embodies information about the interface to that entity - for example, the profile includes information about parameters passed to the callable entity. All callable entities have a profile - enumeration literals, other subprograms, and entries. An access-to-subprogram type has a designated profile.] Associated with a profile is a calling convention. A subprogram_declaration declares a procedure or a function, as indicated by the initial reserved word, with name and profile as given by its specification. 23/2 {AI95-00231-01} {AI95-00318-02} {nominal subtype (of a formal parameter) [partial]} 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. {nominal subtype (of a function result) [partial]} 24/2 {AI95-00231-01} {AI95-00254-01} {AI95-00318-02} {access parameter} An access parameter is a formal in parameter specified by an access_definition. {access result type} An access result type is a function result type specified by an access_definition. An access parameter or result type is of an anonymous access type (see 3.10). [Access parameters of an access-to-object type allow dispatching calls to be controlled by access values. Access parameters of an access-to-subprogram type permit calls to subprograms passed as parameters irrespective of their accessibility level.] 24.a/2 Discussion: {AI95-00318-02} Access result types have normal accessibility and thus don't have any special properties worth noting here. 25 {subtypes (of a profile)} The subtypes of a profile are: 26 * For any non-access parameters, the nominal subtype of the parameter. 27/2 * {AI95-00254-01} For any access parameters of an access-to-object type, the designated subtype of the parameter type. 27.1/2 * {AI95-00254-01} For any access parameters of an access-to-subprogram type, the subtypes of the profile of the parameter type. 28/2 * {AI95-00231-01} {AI95-00318-02} For any non-access result, the nominal subtype of the function result. 28.1/2 * {AI95-00318-02} For any access result type of an access-to-object type, the designated subtype of the result type. 28.2/2 * {AI95-00318-02} For any access result type of an access-to-subprogram type, the subtypes of the profile of the result type. 29 [{types (of a profile)} The types of a profile are the types of those subtypes.] 30/2 {AI95-00348-01} [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 {AI95-00218-03} [An overriding_indicator is used to indicate whether overriding is intended. See 8.3.1, "Overriding Indicators".] Dynamic Semantics 31/2 {AI95-00348-01} {elaboration (subprogram_declaration) [partial]} 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); Extensions to Ada 83 42.a {extensions to Ada 83} The syntax for abstract_subprogram_declaration is added. The syntax for parameter_specification is revised to allow for access parameters (see 3.10) 42.b Program units that are library units may have a parent_unit_name to indicate the parent of a child (see Section 10). Wording Changes from Ada 83 42.c We have incorporated the rules from RM83-6.5, "Function Subprograms" here and in 6.3, "Subprogram Bodies" 42.d We have incorporated the definitions of RM83-6.6, "Parameter and Result Type Profile - Overloading of Subprograms" here. 42.e The syntax rule for defining_operator_symbol is new. It is used for the defining occurrence of an operator_symbol, analogously to defining_identifier. Usage occurrences use the direct_name or selector_name syntactic categories. The syntax rules for defining_designator and defining_program_unit_name are new. Extensions to Ada 95 42.f/2 {AI95-00218-03} {extensions to Ada 95} Subprograms now allow overriding_indicators for better error checking of overriding. 42.g/2 {AI95-00231-01} An optional null_exclusion can be used in a formal parameter declaration. Similarly, an optional null_exclusion can be used in a function result. 42.h/2 {AI95-00318-02} The return type of a function can be an anonymous access type. Wording Changes from Ada 95 42.i/2 {AI95-00254-01} A description of the purpose of anonymous access-to-subprogram parameters and the definition of the profile of subprograms containing them was added. 42.j/2 {AI95-00348-01} Split the production for subprogram_specification in order to make the declaration of null procedures (see 6.7) easier. 42.k/2 {AI95-00348-01} Moved the Syntax and Dynamic Semantics for abstract_subprogram_declaration to 3.9.3, so that the syntax and semantics are together. This also keeps abstract and null subprograms similar. 42.l/2 {AI95-00395-01} Revised to allow other_format characters in operator_symbols in the same way as the underlying constructs. 6.2 Formal Parameter Modes 1 [A parameter_specification declares a formal parameter of mode in, in out, or out.] Static Semantics 2 {pass by copy} {by copy parameter passing} {copy parameter passing} {pass by reference} {by reference parameter passing} {reference parameter passing} 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 {by-copy type} 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 {by-reference type} 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; 7.a Ramification: A limited private type is by-reference only if it falls under one of the other categories. 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. {associated object (of a value of a by-reference type)} 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. 10.a Ramification: By-reference parameter passing makes sense only if there is an object to reference; hence, we define such an object for each case. 10.b Since tagged types are by-reference types, this implies that every value of a tagged type has an associated object. This simplifies things, because we can define the tag to be a property of the object, and not of the value of the object, which makes it clearer that object tags never change. 10.c We considered simplifying things even more by making every value (and therefore every expression) have an associated object. After all, there is little semantic difference between a constant object and a value. However, this would cause problems for untagged types. In particular, we would have to do a constraint check on every read of a type conversion (or a renaming thereof) in certain cases. 10.d/2 {AI95-00318-02} We do not want this definition to depend on the view of the type; privateness is essentially ignored for this definition. Otherwise, things would be confusing (does the rule apply at the call site, at the site of the declaration of the subprogram, at the site of the return statement?), and requiring different calls to use different mechanisms would be an implementation burden. 10.e C.6, "Shared Variable Control" says that a composite type with an atomic or volatile subcomponent is a by-reference type, among other things. 10.f {associated object (of a value of a limited type)} Every value of a limited by-reference type is the value of one and only one limited object. The associated object of a value of a limited by-reference type is the object whose value it represents. {same value (for a limited type)} Two values of a limited by-reference type are the same if and only if they represent the value of the same object. 10.g We say "by-reference" above because these statements are not always true for limited private types whose underlying type is nonlimited (unfortunately). 11 {unspecified [partial]} For parameters of other types, it is unspecified whether the parameter is passed by copy or by reference. 11.a Discussion: There is no need to incorporate the discussion of AI83-00178, which requires pass-by-copy for certain kinds of actual parameters, while allowing pass-by-reference for others. This is because we explicitly indicate that a function creates an anonymous constant object for its result, unless the type is a return-by-reference type (see 6.5). We also provide a special dispensation for instances of Unchecked_Conversion to return by reference, even if the result type is not a return-by-reference type (see 13.9). Bounded (Run-Time) Errors 12 {distinct access paths} {access paths (distinct)} {aliasing: See distinct access paths} {bounded error (cause) [partial]} 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).] {Program_Error (raised by failure of run-time check)} The possible consequences are that Program_Error is raised, or the newly assigned value is read, or some old value of the object is read. 12.a Discussion: For example, if we call "P(X => Global_Variable, Y => Global_Variable)", then within P, the names "X", "Y", and " Global_Variable" are all distinct access paths. If Global_Variable's type is neither pass-by-copy nor pass-by-reference, then it is a bounded error to assign to Global_Variable and then read X or Y, since the language does not specify whether the old or the new value would be read. On the other hand, if Global_Variable's type is pass-by-copy, then the old value would always be read, and there is no error. Similarly, if Global_Variable's type is defined by the language to be pass-by-reference, then the new value would always be read, and again there is no error. 12.b Reason: We are saying assign here, not update, because updating any subcomponent is considered to update the enclosing object. 12.c The "still exists" part is so that a read after the subprogram returns is OK. 12.d If the parameter is of a by-copy type, then there is no issue here - the formal is not a view of the actual. If the parameter is of a by-reference type, then the programmer may depend on updates through one access path being visible through some other access path, just as if the parameter were of an access type. 12.e Implementation Note: The implementation can keep a copy in a register of a parameter whose parameter-passing mechanism is not specified. If a different access path is used to update the object (creating a bounded error situation), then the implementation can still use the value of the register, even though the in-memory version of the object has been changed. However, to keep the error properly bounded, if the implementation chooses to read the in-memory version, it has to be consistent -- it cannot then assume that something it has proven about the register is true of the memory location. For example, suppose the formal parameter is L, the value of L(6) is now in a register, and L(6) is used in an indexed_component as in "A(L(6)) := 99;", where A has bounds 1..3. If the implementation can prove that the value for L(6) in the register is in the range 1..3, then it need not perform the constraint check if it uses the register value. However, if the memory value of L(6) has been changed to 4, and the implementation uses that memory value, then it had better not alter memory outside of A. 12.f Note that the rule allows the implementation to pass a parameter by reference and then keep just part of it in a register, or, equivalently, to pass part of the parameter by reference and another part by copy. 12.g Reason: We do not want to go so far as to say that the mere presence of aliasing is wrong. We wish to be able to write the following sorts of things in standard Ada: 12.h procedure Move ( Source : in String; Target : out String; Drop : in Truncation := Error; Justify : in Alignment := Left; Pad : in Character := Space); -- Copies elements from Source to Target (safely if they overlap) 12.i This is from the standard string handling package. It would be embarrassing if this couldn't be written in Ada! 12.j The "then" before "read" in the rule implies that the implementation can move a read to an earlier place in the code, but not to a later place after a potentially aliased assignment. Thus, if the subprogram reads one of its parameters into a local variable, and then updates another potentially aliased one, the local copy is safe - it is known to have the old value. For example, the above-mentioned Move subprogram can be implemented by copying Source into a local variable before assigning into Target. 12.k For an assignment_statement assigning one array parameter to another, the implementation has to check which direction to copy at run time, in general, in case the actual parameters are overlapping slices. For example: 12.l procedure Copy(X : in out String; Y: String) is begin X := Y; end Copy; 12.m It would be wrong for the compiler to assume that X and Y do not overlap (unless, of course, it can prove otherwise). NOTES 13 5 A formal parameter of mode in is a constant view (see 3.3); it cannot be updated within the subprogram_body. Extensions to Ada 83 13.a {extensions to Ada 83} The value of an out parameter may be read. An out parameter is treated like a declared variable without an explicit initial expression. Wording Changes from Ada 83 13.b Discussion of copy-in for parts of out parameters is now covered in 6.4.1, "Parameter Associations". 13.c The concept of a by-reference type is new to Ada 95. 13.d We now cover in a general way in 3.7.2 the rule regarding erroneous execution when a discriminant is changed and one of the parameters depends on the discriminant. 6.3 Subprogram Bodies 1 [A subprogram_body specifies the execution of a subprogram.] Syntax 2/2 {AI95-00218-03} 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. {full conformance (required)} 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 {elaboration (non-generic subprogram_body) [partial]} 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. 6.a Ramification: See 12.2 for elaboration of a generic body. Note that protected subprogram_bodies never get elaborated; the elaboration of the containing protected_body allows them to be called without failing the Elaboration_Check. 7 {execution (subprogram_body) [partial]} [The execution of a subprogram_body is invoked by a subprogram call.] For this execution the declarative_part is elaborated, and the handled_sequence_of_statements is then executed. Examples 8 Example of procedure body: 9 procedure Push(E : in Element_Type; S : in out Stack) is begin if S.Index = S.Size then raise Stack_Overflow; else S.Index := S.Index + 1; S.Space(S.Index) := E; end if; end Push; 10 Example of a function body: 11 function Dot_Product(Left, Right : Vector) return Real is Sum : Real := 0.0; begin Check(Left'First = Right'First and Left'Last = Right'Last); for J in Left'Range loop Sum := Sum + Left(J)*Right(J); end loop; return Sum; end Dot_Product; Extensions to Ada 83 11.a {extensions to Ada 83} A renaming_declaration may be used instead of a subprogram_body. Wording Changes from Ada 83 11.b The syntax rule for subprogram_body now uses the syntactic category handled_sequence_of_statements. 11.c The declarative_part of a subprogram_body is now required; that doesn't make any real difference, because a declarative_part can be empty. 11.d We have incorporated some rules from RM83-6.5 here. 11.e RM83 forgot to restrict the definition of elaboration of a subprogram_body to non-generics. Wording Changes from Ada 95 11.f/2 {AI95-00218-03} Overriding_indicator is added to subprogram_body. 6.3.1 Conformance Rules 1 {conformance} [When subprogram profiles are given in more than one place, they are required to conform in one of four ways: type conformance, mode conformance, subtype conformance, or full conformance.] Static Semantics 2/1 {8652/0011} {AI95-00117-01} {convention} {calling convention} [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 * {Ada calling convention} {calling convention (Ada)} 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)]. 3.a Ramification: See also the rule about renamings-as-body in 8.5.4. 4 * {Intrinsic calling convention} {calling convention (Intrinsic)} The Intrinsic calling convention represents subprograms that are "built in" to the compiler. The default calling convention is Intrinsic for the following: 5 * an enumeration literal; 6 * a "/=" operator declared implicitly due to the declaration of "=" (see 6.6); 7 * any other implicitly declared subprogram unless it is a dispatching operation of a tagged type; 8 * an inherited subprogram of a generic formal tagged type with unknown discriminants; 8.a.1/1 Reason: Consider: 8.a.2/1 package P is type Root is tagged null record; procedure Proc(X: Root); end P; 8.a.3/1 generic type Formal(<>) is new Root with private; package G is ... end G; 8.a.4/1 package body G is ... X: Formal := ...; ... Proc(X); -- This is a dispatching call in Instance, because -- the actual type for Formal is class-wide. ... -- Proc'Access would be illegal here, because it is of -- convention Intrinsic, by the above rule. end G; 8.a.5/1 type Actual is new Root with ...; procedure Proc(X: Actual); package Instance is new G(Formal => Actual'Class); -- It is legal to pass in a class-wide actual, because Formal -- has unknown discriminants. 8.a.6/1 Within Instance, all calls to Proc will be dispatching calls, so Proc doesn't really exist in machine code, so we wish to avoid taking 'Access of it. This rule applies to those cases where the actual type might be class-wide, and makes these Intrinsic, thus forbidding 'Access. 9 * an attribute that is a subprogram; 10/2 * {AI95-00252-01} a subprogram declared immediately within a protected_body; 10.1/2 * {AI95-00252-01} {AI95-00407-01} any prefixed view of a subprogram (see 4.1.3). 10.a/2 Reason: The profile of a prefixed view is different than the " real" profile of the subprogram (it doesn't have the first parameter), so we don't want to be able to take 'Access of it, as that would require generating a wrapper of some sort. 11 [The Access attribute is not allowed for Intrinsic subprograms.] 11.a Ramification: The Intrinsic calling convention really represents any number of calling conventions at the machine code level; the compiler might have a different instruction sequence for each intrinsic. That's why the Access attribute is disallowed. We do not wish to require the implementation to generate an out of line body for an intrinsic. 11.b Whenever we wish to disallow the Access attribute in order to ease implementation, we make the subprogram Intrinsic. Several language-defined subprograms have "pragma Convention(Intrinsic, ...);". An implementation might actually implement this as " pragma Import(Intrinsic, ...);", if there is really no body, and the implementation of the subprogram is built into the code generator. 11.c Subprograms declared in protected_bodies will generally have a special calling convention so as to pass along the identification of the current instance of the protected type. The convention is not protected since such local subprograms need not contain any "locking" logic since they are not callable via "external" calls; this rule prevents an access value designating such a subprogram from being passed outside the protected unit. 11.d The "implicitly declared subprogram" above refers to predefined operators (other than the "=" of a tagged type) and the inherited subprograms of untagged types. 12 * {protected calling convention} {calling convention (protected)} 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 * {entry calling convention} {calling convention (entry)} The default calling convention is entry for an entry. 13.1/2 * {AI95-00254-01} {AI95-00409-01} 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.a/2 Ramification: The calling convention for other anonymous access-to-subprogram types is Ada. 13.2/1 * {8652/0011} {AI95-00117-01} [If not specified above as Intrinsic, the calling convention for any inherited or overriding dispatching operation of a tagged type is that of the corresponding subprogram of the parent type.] The default calling convention for a new dispatching operation of a tagged type is the convention of the type. 13.a.1/1 Reason: The first rule is officially stated in 3.9.2. The second is intended to make interfacing to foreign OOP languages easier, by making the default be that the type and operations all have the same convention. 14 Of these four conventions, only Ada and Intrinsic are allowed as a convention_identifier in a pragma Convention, Import, or Export. 14.a Discussion: The names of the protected and entry calling conventions cannot be used in the interfacing pragmas. Note that protected and entry are reserved words. 15/2 {AI95-00409-01} {type conformance} {profile (type conformant)} 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. {type profile: See profile, type conformant} 15.a/2 Discussion: {AI95-00409-01} For anonymous access-to-object parameters, the designated types have to be the same for type conformance, not the access types, since in general each access parameter has its own anonymous access type, created when the subprogram is called. Of course, corresponding parameters have to be either both access parameters or both not access parameters. 15.b/2 {AI95-00409-01} Similarly, for anonymous access-to-subprogram parameters, the designated profiles of the types, not the types themselves, have to be conformant. 16/2 {AI95-00318-02} {AI95-00409-01} {mode conformance} {profile (mode conformant)} 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. {statically matching (required) [partial]} 17 {subtype conformance} {profile (subtype conformant)} 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. {statically matching (required) [partial]} 17.a Ramification: {generic contract issue [partial]} 18 {full conformance (for profiles)} {profile (fully conformant)} 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. 18.a Ramification: Full conformance requires subtype conformance, which requires the same calling conventions. However, the calling convention of the declaration and body of a subprogram or entry are always the same by definition. 19 {full conformance (for expressions)} 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.a Ramification: Note that it doesn't say "respectively" because a direct_name can correspond to a selector_name, and vice-versa, by the previous bullet. This rule allows the prefix of an expanded name to be removed, or replaced with a different prefix that denotes a renaming of the same entity. However, it does not allow a direct_name or selector_name to be replaced with one denoting a distinct renaming (except for direct_names and selector_names in prefixes of expanded names). Note that calls using operator notation are equivalent to calls using prefix notation. 21.b Given the following declarations: 21.c package A is function F(X : Integer := 1) return Boolean; end A; 21.d with A; package B is package A_View renames A; function F_View(X : Integer := 9999) return Boolean renames F; end B; 21.e with A, B; use A, B; procedure Main is ... 21.f Within Main, the expressions "F", "A.F", "B.A_View.F", and " A_View.F" are all fully conformant with one another. However, " F" and "F_View" are not fully conformant. If they were, it would be bad news, since the two denoted views have different default_expressions. 21.1/1 * {8652/0018} {AI95-00175-01} 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. 22.a Ramification: The literals may be written differently. 22.b Ramification: Note that the above definition makes full conformance a transitive relation. 23 {full conformance (for known_discriminant_parts)} 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. {statically matching (required) [partial]} 24 {full conformance (for discrete_subtype_definitions)} Two discrete_subtype_definitions are fully conformant if they are both subtype_indications or are both ranges, the subtype_marks (if any) denote the same subtype, and the corresponding simple_expressions of the ranges (if any) fully conform. 24.a Ramification: In the subtype_indication case, any ranges have to be corresponding; that is, two subtype_indications cannot conform unless both or neither has a range. 24.b Discussion: This definition is used in 9.5.2, " Entries and Accept Statements" for the conformance required between the discrete_subtype_definitions of an entry_declaration for a family of entries and the corresponding entry_index_specification of the entry_body. 24.1/2 {AI95-00345-01} {AI95-00397-01} {prefixed view profile} The prefixed view profile of a subprogram is the profile obtained by omitting the first parameter of that subprogram. There is no prefixed view profile for a parameterless subprogram. For the purposes of defining subtype and mode conformance, the convention of a prefixed view profile is considered to match that of either an entry or a protected operation. 24.c/2 Discussion: This definition is used to define how primitive subprograms of interfaces match operations in task and protected type definitions (see 9.1 and 9.4). 24.d/2 Reason: The weird rule about conventions is pretty much required for synchronized interfaces to make any sense. There will be wrappers all over the place for interfaces anyway. Of course, this doesn't imply that entries have the same convention as protected operations. Implementation Permissions 25 An implementation may declare an operator declared in a language-defined library unit to be intrinsic. Extensions to Ada 83 25.a {extensions to Ada 83} The rules for full conformance are relaxed - they are now based on the structure of constructs, rather than the sequence of lexical elements. This implies, for example, that "(X, Y: T)" conforms fully with "(X: T; Y: T)", and "(X: T)" conforms fully with "(X: in T)". Wording Changes from Ada 95 25.b/2 {8652/0011} {AI95-00117-01} Corrigendum: Clarified that the default convention is Ada. Also clarified that the convention of a primitive operation of a tagged type is the same as that of the type. 25.c/2 {8652/0018} {AI95-00175-01} Corrigendum: Added wording to ensure that two attributes conform only if they have the same attribute_designator. 25.d/2 {AI95-00252-01} {AI95-00254-01} {AI95-00407-01} Defined the calling convention for anonymous access-to-subprogram types and for prefixed views of subprograms (see 4.1.3). 25.e/2 {AI95-00318-02} Defined the conformance of access result types (see 6.1). 25.f/2 {AI95-00345-01} {AI95-00397-01} Defined the prefixed view profile of subprograms for later use. 25.g/2 {AI95-00409-01} Defined the conformance of anonymous access-to-subprogram parameters. 6.3.2 Inline Expansion of Subprograms 1 [Subprograms may be expanded in line at the call site.] Syntax 2 {program unit pragma (Inline) [partial]} {pragma, program unit (Inline) [partial]} 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. 5.a Ramification: Note that inline expansion is desired no matter what name is used in the call. This allows one to request inlining for only one of several overloaded subprograms as follows: 5.b package IO is procedure Put(X : in Integer); procedure Put(X : in String); procedure Put(X : in Character); private procedure Character_Put(X : in Character) renames Put; pragma Inline(Character_Put); end IO; 5.c with IO; use IO; procedure Main is I : Integer; C : Character; begin ... Put(C); -- Inline expansion is desired. Put(I); -- Inline expansion is NOT desired. end Main; 5.d Ramification: The meaning of a subprogram can be changed by a pragma Inline only in the presence of failing checks (see 11.6). Implementation Permissions 6 For each call, an implementation is free to follow or to ignore the recommendation expressed by the pragma. 6.a Ramification: Note, in particular, that the recommendation cannot always be followed for a recursive call, and is often infeasible for entries. Note also that the implementation can inline calls even when no such desire was expressed by a pragma, so long as the semantics of the program remains unchanged. 6.1/2 {AI95-00309-01} 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. 6.b/2 Reason: This is allowed for Ada 83 compatibility. This is only a permission as this usage is considered obsolescent. 6.c/2 Discussion: We only need to allow this in declarative_parts, because a body is only allowed in another body, and these all have declarative_parts. 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. Incompatibilities With Ada 83 7.a/2 {AI95-00309-01} {incompatibilities with Ada 83} A pragma Inline cannot refer to a subprogram_body outside of that body. The pragma can be given inside of the subprogram body. Ada 2005 adds an Implementation Permission to allow this usage for compatibility (and Ada 95 implementations also can use this permission), but implementations do not have to allow such pragmas. Extensions to Ada 83 7.b {extensions to Ada 83} A pragma Inline is allowed inside a subprogram_body if there is no corresponding subprogram_declaration. This is for uniformity with other program unit pragmas. Extensions to Ada 95 7.c/2 {AI95-00309-01} {extensions to Ada 95} Amendment Correction: Implementations are allowed to let Pragma Inline apply to a subprogram_body. 6.4 Subprogram Calls 1 {subprogram call} 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 {named association} {positional association} A parameter_association is named or positional according to whether or not the formal_parameter_selector_name is specified. Any positional associations shall precede any named associations. Named associations are not allowed if the prefix in a subprogram call is an attribute_- reference. 7.a Ramification: This means that the formal parameter names used in describing predefined attributes are to aid presentation of their semantics, but are not intended for use in actual calls. Name Resolution Rules 8/2 {AI95-00310-01} The name or prefix given in a procedure_call_statement shall resolve to denote a callable entity that is a procedure, or an entry renamed as (viewed as) a procedure. The name or prefix given in a function_call shall resolve to denote a callable entity that is a function. The name or prefix shall not resolve to denote an abstract subprogram unless it is also a dispatching subprogram. [When there is an actual_parameter_- part, the prefix can be an implicit_dereference of an access-to-subprogram value.] 8.a.1/2 Discussion: {AI95-00310-01} This rule is talking about dispatching operations (which is a static concept) and not about dispatching calls (which is a dynamic concept). 8.a Ramification: The function can be an operator, enumeration literal, attribute that is a function, etc. 9 A subprogram call shall contain at most one association for each formal parameter. Each formal parameter without an association shall have a default_expression (in the profile of the view denoted by the name or prefix ). This rule is an overloading rule (see 8.6). Dynamic Semantics 10/2 {AI95-00345-01} {execution (subprogram call) [partial]} For the execution of a subprogram call, the name or prefix of the call is evaluated, and each parameter_association is evaluated (see 6.4.1). If a default_expression is used, an implicit parameter_association is assumed for this rule. These evaluations are done in an arbitrary order. The subprogram_body is then executed, or a call on an entry or protected subprogram is performed (see 3.9.2). Finally, if the subprogram completes normally, then after it is left, any necessary assigning back of formal to actual parameters occurs (see 6.4.1). 10.a Discussion: The implicit association for a default is only for this run-time rule. At compile time, the visibility rules are applied to the default at the place where it occurs, not at the place of a call. 10.b To be honest: If the subprogram is inherited, see 3.4, " Derived Types and Classes". 10.c If the subprogram is protected, see 9.5.1, " Protected Subprograms and Protected Actions". 10.d If the subprogram is really a renaming of an entry, see 9.5.3, "Entry Calls". 10.d.1/2 {AI95-00345-01} If the subprogram is implemented by an entry or protected subprogram, it will be treated as a dispatching call to the corresponding entry (see 9.5.3, "Entry Calls") or protected subprogram (see 9.5.1, " Protected Subprograms and Protected Actions"). 10.e/2 {AI95-00348-01} Normally, the subprogram_body that is executed by the above rule is the one for the subprogram being called. For an enumeration literal, implicitly declared (but noninherited) subprogram, null procedure, or an attribute that is a subprogram, an implicit body is assumed. For a dispatching call, 3.9.2, " Dispatching Operations of Tagged Types" defines which subprogram_body is executed. 10.1/2 {AI95-00407-01} If the name or prefix of a subprogram call denotes a prefixed view (see 4.1.3), the subprogram call is equivalent to a call on the underlying subprogram, with the first actual parameter being provided by the prefix of the prefixed view (or the Access attribute of this prefix if the first formal parameter is an access parameter), and the remaining actual parameters given by the actual_parameter_part, if any. 11/2 {AI95-00318-02} {Program_Error (raised by failure of run-time check)} The exception Program_Error is raised at the point of a function_call if the function completes normally without executing a return statement. 11.a Discussion: We are committing to raising the exception at the point of call, for uniformity - see AI83-00152. This happens after the function is left, of course. 11.b Note that there is no name for suppressing this check, since the check imposes no time overhead and minimal space overhead (since it can usually be statically eliminated as dead code). 12/2 {AI95-00231-01} A function_call denotes a constant, as defined in 6.5; the nominal subtype of the constant is given by the nominal subtype of the function result. {nominal subtype (of the result of a function_call) [partial]} {constant (result of a function_call) [partial]} 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 Wording Changes from Ada 83 31.a We have gotten rid of parameters "of the form of a type conversion" (see RM83-6.4.1(3)). The new view semantics of type_conversions allows us to use normal type_conversions instead. 31.b We have moved wording about run-time semantics of parameter associations to 6.4.1. 31.c We have moved wording about raising Program_Error for a function that falls off the end to here from RM83-6.5. Extensions to Ada 95 31.d/2 {AI95-00310-01} {extensions to Ada 95} Nondispatching abstract operations are no longer considered when resolving a subprogram call. That makes it possible to use abstract to "undefine" a predefined operation for an untagged type. That's especially helpful when defining custom arithmetic packages. Wording Changes from Ada 95 31.e/2 {AI95-00231-01} Changed the definition of the nominal subtype of a function_call to use the nominal subtype wording of 6.1, to take into account null_exclusions and access result types. 31.f/2 {AI95-00345-01} Added wording to clarify that the meaning of a call on a subprogram "implemented by" an entry or protected operation is defined by 3.9.2. 31.g/2 {AI95-00407-01} Defined the meaning of a call on a prefixed view of a subprogram (see 4.1.3). 6.4.1 Parameter Associations 1 [{parameter passing} A parameter association defines the association between an actual parameter and a formal parameter.] Language Design Principles 1.a The parameter passing rules for out parameters are designed to ensure that the parts of a type that have implicit initial values (see 3.3.1) don't become "de-initialized" by being passed as an out parameter. 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 {actual parameter (for a formal parameter)} 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. {expected type (actual parameter)} The expected type for an actual parameter is the type of the corresponding formal parameter. 3.a To be honest: The corresponding default_expression is the one of the corresponding formal parameter in the profile of the view denoted by the name or prefix of the call. 4 If the mode is in, the actual is interpreted as an expression; otherwise, the actual is interpreted only as a name, if possible. 4.a Ramification: This formally resolves the ambiguity present in the syntax rule for explicit_actual_parameter. Note that we don't actually require that the actual be a name if the mode is not in; we do that below. Legality Rules 5 If the mode is in out or out, the actual shall be a name that denotes a variable. 5.a Discussion: We no longer need "or a type_conversion whose argument is the name of a variable," because a type_conversion is now a name, and a type_conversion of a variable is a variable. 5.b Reason: The requirement that the actual be a (variable) name is not an overload resolution rule, since we don't want the difference between expression and name to be used to resolve overloading. For example: 5.c procedure Print(X : in Integer; Y : in Boolean := True); procedure Print(Z : in out Integer); . . . Print(3); -- Ambiguous! 5.d The above call to Print is ambiguous even though the call is not compatible with the second Print which requires an actual that is a (variable) name ("3" is an expression, not a name). This requirement is a legality rule, so overload resolution fails before it is considered, meaning that the call is ambiguous. 6 The type of the actual parameter associated with an access parameter shall be convertible (see 4.6) to its anonymous access type. {convertible (required) [partial]} Dynamic Semantics 7 {evaluation (parameter_association) [partial]} 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. {implicit subtype conversion (parameter passing) [partial]} 10.a Discussion: We are always allowing sliding, even for [in[ out by-reference parameters. 11 * {assignment operation (during evaluation of a parameter_association)} 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. {implicit subtype conversion (parameter passing) [partial]} 11.a Ramification: The conversion mentioned here is a value conversion. 12 * For an out parameter that is passed by copy, the formal parameter object is created, and: 13 * For an access type, the formal parameter is initialized from the value of the actual, without a constraint check; 13.a Reason: This preserves the Language Design Principle that an object of an access type is always initialized with a " reasonable" value. 14 * For a composite type with discriminants or that has implicit initial values for any subcomponents (see 3.3.1), the behavior is as for an in out parameter passed by copy. 14.a Reason: This ensures that no part of an object of such a type can become "de-initialized" by being part of an out parameter. 14.b Ramification: This includes an array type whose component type is an access type, and a record type with a component that has a default_expression, among other things. 15 * For any other type, the formal parameter is uninitialized. If composite, a view conversion of the actual parameter to the nominal subtype of the formal is evaluated [(which might raise Constraint_Error)], and the actual subtype of the formal is that of the view conversion. If elementary, the actual subtype of the formal is given by its nominal subtype. 15.a Ramification: This case covers scalar types, and composite types whose subcomponent's subtypes do not have any implicit initial values. The view conversion for composite types ensures that if the lengths don't match between an actual and a formal array parameter, the Constraint_Error is raised before the call, rather than after. 16 {constrained (object) [partial]} {unconstrained (object) [partial]} 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 {parameter copy back} {copy back of parameters} {parameter assigning back} {assigning back of parameters} {assignment operation (during parameter copy back)} 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. {implicit subtype conversion (parameter passing) [partial]} These conversions and assignments occur in an arbitrary order. 17.a Ramification: The conversions mentioned above during parameter passing might raise Constraint_Error - (see 4.6). 17.b Ramification: If any conversion or assignment as part of parameter passing propagates an exception, the exception is raised at the place of the subprogram call; that is, it cannot be handled inside the subprogram_body. 17.c Proof: Since these checks happen before or after executing the subprogram_body, the execution of the subprogram_body does not dynamically enclose them, so it can't handle the exceptions. 17.d Discussion: The variable we're talking about is the one denoted by the variable_name given as the explicit_actual_parameter. If this variable_name is a type_conversion, then the rules in 4.6 for assigning to a view conversion apply. That is, if X is of subtype S1, and the actual is S2(X), the above-mentioned conversion will convert to S2, and the one mentioned in 4.6 will convert to S1. Extensions to Ada 83 17.e {extensions to Ada 83} In Ada 95, a program can rely on the fact that passing an object as an out parameter does not " de-initialize" any parts of the object whose subtypes have implicit initial values. (This generalizes the RM83 rule that required copy-in for parts that were discriminants or of an access type.) Wording Changes from Ada 83 17.f We have eliminated the subclause on Default Parameters, as it is subsumed by earlier clauses and subclauses. 6.5 Return Statements 1/2 {AI95-00318-02} A simple_return_statement or extended_return_statement (collectively called a return statement) {return statement} is used to complete the execution of the innermost enclosing subprogram_body, entry_- body, or accept_statement. Syntax 2/2 {AI95-00318-02} simple_return_statement ::= return [expression]; 2.1/2 {AI95-00318-02} extended_return_statement ::= return defining_identifier : [aliased] return_subtype_indication [:= expression] [do handled_sequence_of_statements end return]; 2.2/2 {AI95-00318-02} return_subtype_indication ::= subtype_indication | access_definition Name Resolution Rules 3/2 {AI95-00318-02} {result subtype (of a function)} 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.{expected type (expression of simple_return_statement) [partial]} The expected type for the expression, if any, of a simple_return_statement is the result type of the corresponding function. {expected type (expression of extended_return_statement) [partial]} The expected type for the expression of an extended_return_statement is that of the return_subtype_indication. 3.a To be honest: The same applies to generic functions. Legality Rules 4/2 {AI95-00318-02} {apply (to a callable construct by a return statement)} 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 {AI95-00318-02} 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.a/2 Reason: {AI95-00318-02} The requirement that a function body has to have at least one return statement is a "helpful" restriction. There has been some interest in lifting this restriction, or allowing a raise statement to substitute for the return statement. However, there was enough interest in leaving it as is that we decided not to change it. 5.b/2 Ramification: {AI95-00318-02} A return statement can apply to an extended_return_statement, so a simple_return_statement without an expression can be given in one. However, neither simple_return_- statement with an expression nor an extended_return_statement can be given inside an extended_return_statement, as they must apply (directly) to a function body. 5.1/2 {AI95-00318-02} For an extended_return_statement that applies to a function body: 5.2/2 * {AI95-00318-02} 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. {statically matching (required) [partial]} 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 * {AI95-00318-02} If the result subtype of the function is defined by an access_definition, the return_subtype_indication shall be an access_definition. The subtype defined by the access_definition shall statically match the result subtype of the function. The accessibility level of this anonymous access subtype is that of the result subtype. 5.4/2 {AI95-00318-02} For any return statement that applies to a function body: 5.5/2 * {AI95-00318-02} 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.c/2 Discussion: In other words, if limited, the expression must produce a "new" object, rather than being the name of a preexisting object (which would imply copying). 5.6/2 * {AI95-00416-01} 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. 5.d/2 Discussion: We know that if the result type is class wide, then there must be an expression of the return statement. Similarly, if the result subtype is unconstrained, then either the return_- subtype_indication (if any) is constrained, or there must be an expression. Static Semantics 5.7/2 {AI95-00318-02} {return object (extended_return_statement) [partial]} 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 {AI95-00318-02} {AI95-00416-01} {execution (extended_return_statement) [partial]} 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{implicit subtype conversion (function return) [partial]} ); 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.{creation (of a return object) [partial]} 5.e/2 Ramification: If the result type is controlled or has a controlled part, appropriate calls on Initialize or Adjust are performed prior to executing the handled_sequence_of_statements, except when the initial expression is an aggregate (which requires build-in-place with no call on Adjust). 5.f/2 If the return statement is left without resulting in a return (for example, due to an exception propagated from the expression or the handled_sequence_of_statements, or a goto out of the handled_sequence_of_statements), the return object is finalized prior to leaving the return statement. 6/2 {AI95-00318-02} {execution (simple_return_statement) [partial]} 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. {return object (simple_return_statement) [partial]} {implicit subtype conversion (function return) [partial]} 6.a Ramification: The conversion might raise Constraint_Error - (see 4.6). 7/2 {AI95-00318-02} {AI95-00416-01} [If the return object has any parts that are tasks, the activation of those tasks does not occur until after the function returns (see 9.2).] 7.a/2 Proof: This is specified by the rules in 9.2. 7.b/2 Reason: Only the caller can know when task activations should take place, as it depends on the context of the call. If the function is being used to initialize the component of some larger object, then that entire object must be initialized before any task activations. Even after the outer object is fully initialized, task activations are still postponed until the begin at the end of the declarative part if the function is being used to initialize part of a declared object. 8/2 {AI95-00318-02} {AI95-00344-01} 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.{Program_Error (raised by failure of run-time check)} {Accessibility_Check [partial]} {check, language-defined (Accessibility_Check)} 8.a/2 Ramification: {AI95-00318-02} The first sentence is true even if the tag of the expression is different, which could happen if the expression were a view conversion or a dereference of an access value. Note that for a limited type, because of the restriction to aggregates and function calls (and no conversions), the tag will already match. 8.b/2 Reason: {AI95-00318-02} The first rule ensures that a function whose result type is a specific tagged type always returns an object whose tag is that of the result type. This is important for dispatching on controlling result, and allows the caller to allocate the appropriate amount of space to hold the value being returned (assuming there are no discriminants). 8.c/2 The check prevents the returned object from outliving its type. Note that this check cannot fail for a specific tagged type, as the tag represents the function's type, which necessarily must be declared outside of the function. Paragraphs 9 through 20 were deleted. 21/2 {AI95-00318-02} {AI95-00402-01} {AI95-00416-01} 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. {Program_Error (raised by failure of run-time check)} {Accessibility_Check [partial]} {check, language-defined (Accessibility_Check)} 21.a/2 This paragraph was deleted. 21.b/2 Reason: The check prevents the returned object (for a nonlimited type) from outliving the object designated by one of its discriminants. The check is made on the values of the discriminants, which may come from the return_subtype_indication (if constrained), or the expression, but it is never necessary to check both. 22/2 {AI95-00318-02} 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 {AI95-00318-02} In the case of a function, the function_call denotes a constant view of the return object. Implementation Permissions 24/2 {AI95-00416-01} 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. 24.a/2 Reason: Without such a permission, it would be very difficult to implement "build-in-place" semantics. Such an exception is not handleable within the function, because in the return-by-copy case, the constraint check to verify that the result satisfies the constraints of the object being initialized happens after the function returns, and we want the semantics to change as little as possible when switching between return-by-copy and build-in-place. This implies further that upon detecting such a situation, the implementation may need to simulate a goto to a point outside any local exception handlers prior to raising the exception. 24.b/2 Ramification: This permission is allowed during the evaluation of the expression of an extended_return_statement, because the return_- subtype_indication may be unconstrained and the expression then would provide the constraints. Examples 25 Examples of return statements: 26/2 {AI95-00318-02} return; -- in a procedure body, entry_body, -- accept_statement , or extended_return_statement 27 return Key_Value(Last_Index); -- in a function body 28/2 {AI95-00318-02} return Node : Cell do -- in a function body, see 3.10.1 for Cell Node.Value := Result; Node.Succ := Next_Node; end return; Incompatibilities With Ada 83 28.a/2 {AI95-00318-02} {incompatibilities with Ada 83} In Ada 95, if the result type of a function has a part that is a task, then an attempt to return a local variable will raise Program_Error. This is illegal in Ada 2005, see below. In Ada 83, if a function returns a local variable containing a task, execution is erroneous according to AI83-00867. However, there are other situations where functions that return tasks (or that return a variant record only one of whose variants includes a task) are correct in Ada 83 but will raise Program_Error according to the new rules. 28.b The rule change was made because there will be more types (protected types, limited controlled types) in Ada 95 for which it will be meaningless to return a local variable, and making all of these erroneous is unacceptable. The current rule was felt to be the simplest that kept upward incompatibilities to situations involving returning tasks, which are quite rare. Wording Changes from Ada 83 28.c This clause has been moved here from chapter 5, since it has mainly to do with subprograms. 28.d A function now creates an anonymous object. This is necessary so that controlled types will work. 28.e/2 {AI95-00318-02} We have clarified that a return statement applies to a callable construct, not to a callable entity. 28.f/2 {AI95-00318-02} There is no need to mention generics in the rules about where a return statement can appear and what it applies to; the phrase "body of a subprogram or generic subprogram" is syntactic, and refers exactly to "subprogram_body". Incompatibilities With Ada 95 28.g/2 {AI95-00318-02} {incompatibilities with Ada 95} The entire business about return-by-reference types has been dropped. Instead, the expression of a return statement of a limited type can only be an aggregate or function_call (see 7.5). This means that returning a global object or type_conversion, legal in Ada 95, is now illegal. Such functions can be converted to use anonymous access return types by adding access in the function definition and return statement, adding .all in uses, and adding aliased in the object declarations. This has the advantage of making the reference return semantics much clearer to the casual reader. 28.h/2 We changed these rules so that functions, combined with the new rules for limited types (7.5), can be used as build-in-place constructors for limited types. This reduces the differences between limited and nonlimited types, which will make limited types useful in more circumstances. Extensions to Ada 95 28.i/2 {AI95-00318-02} {extensions to Ada 95} The extended_return_statement is new. This provides a name for the object being returned, which reduces the copying needed to return complex objects (including no copying at all for limited objects). It also allows component-by-component construction of the return object. Wording Changes from Ada 95 28.j/2 {AI95-00318-02} The wording was updated to support anonymous access return subtypes. 28.k/2 {AI95-00318-02} The term "return expression" was dropped because reviewers found it confusing when applied to the default expression of an extended_return_statement. 28.l/2 {AI95-00344-01} {AI95-00416-01} Added accessibility checks to class-wide return statements. These checks could not fail in Ada 95 (as all of the types had to be declared at the same level, so the tagged type would necessarily have been at the same level as the type of the object). 28.m/2 {AI95-00402-01} {AI95-00416-01} Added accessibility checks to return statements for types with access discriminants. Since such types have to be limited in Ada 95, the expression of a return statement would have been illegal in order for this check to fail. 28.n/2 {AI95-00416-01} Added an Implementation Permission allowing early raising of Constraint_Error if the result cannot fit in the ultimate object. This gives implementations more flexibility to do built-in-place returns, and is essential for limited types (which cannot be built in a temporary). 6.5.1 Pragma No_Return 1/2 {AI95-00329-01} {AI95-00414-01} A pragma No_Return indicates that a procedure cannot return normally[; it may propagate an exception or loop forever]. 1.a/2 Discussion: Pragma No_Deposit will have to wait for Ada 2017. :-) Syntax 2/2 {AI95-00329-01} {AI95-00414-01} 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 {AI95-00329-01} {AI95-00414-01} {non-returning} 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. 4.a/2 Reason: A null procedure cannot have the appropriate non-returning semantics, as it does not raise an exception or loop forever. 4.b/2 Ramification: The procedure can be abstract. The denoted declaration can be a renaming_declaration if it obeys the usual rules for representation pragmas: the renaming has to occur immediately within the same declarative region as the renamed subprogram. If a non-returning procedure is renamed (anywhere) calls through the new name still have the non-returning semantics. 5/2 {AI95-00329-01} {AI95-00414-01} A return statement shall not apply to a non-returning procedure or generic procedure. 6/2 {AI95-00414-01} A procedure shall be non-returning if it overrides a dispatching non-returning procedure. {generic contract issue [partial]} In addition to the places where Legality Rules normally apply (see 12.3), this rule applies also in the private part of an instance of a generic unit. 6.a/2 Reason: This ensures that dispatching calls to non-returning procedures will, in fact, not return. 7/2 {AI95-00414-01} If a renaming-as-body completes a non-returning procedure declaration, then the renamed procedure shall be non-returning. 7.a/2 Reason: This ensures that no extra code is needed to implement the renames (that is, no wrapper is needed) as the body has the same property. Static Semantics 8/2 {AI95-00329-01} {AI95-00414-01} 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 {AI95-00329-01} {AI95-00414-01} If the body of a non-returning procedure completes normally, Program_Error is raised at the point of the call. {Program_Error (raised by failure of run-time check)} 9.a/2 Discussion: Note that there is no name for suppressing this check, since the check represents a bug, imposes no time overhead, and minimal space overhead (since it can usually be statically eliminated as dead code). 9.b/2 Implementation Note: If a non-returning procedure tries to return, we raise Program_Error. This is stated as happening at the call site, because we do not wish to allow the procedure to handle the exception (and then, perhaps, try to return again!). However, the expected run-time model is that the compiler will generate raise Program_Error at the end of the procedure body (but not handleable by the procedure itself), as opposed to doing it at the call site. (This is just like the typical run-time model for functions that fall off the end without returning a value). The reason is indirect calls: in P.all(...);, the compiler cannot know whether P designates a non-returning procedure or a normal one. Putting the raise Program_Error in the procedure's generated code solves this problem neatly. 9.c/2 Similarly, if one passes a non-returning procedure to a generic formal parameter, the compiler cannot know this at call sites (in shared code implementations); the raise-in-body solution deals with this neatly. Examples 10/2 {AI95-00433-01} procedure Fail(Msg : String); -- raises Fatal_Error exception pragma No_Return(Fail); -- Inform compiler and reader that procedure never returns normally Extensions to Ada 95 10.a/2 {AI95-00329-01} {AI95-00414-01} {extensions to Ada 95} Pragma No_Return is new. 6.6 Overloading of Operators 1 {operator} {user-defined operator} {operator (user-defined)} An operator is a function whose designator is an operator_symbol. [Operators, like other functions, may be overloaded.] Name Resolution Rules 2 Each use of a unary or binary operator is equivalent to a function_call with function_prefix being the corresponding operator_symbol, and with (respectively) one or two positional actual parameters being the operand(s) of the operator (in order). 2.a To be honest: We also use the term operator (in Section 4 and in 6.1) to refer to one of the syntactic categories defined in 4.5 , "Operators and Expression Evaluation" whose names end with " _operator:" logical_operator, relational_operator, binary_adding_- operator, unary_adding_operator, multiplying_operator, and highest_- precedence_operator. 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); Extensions to Ada 83 9.a {extensions to Ada 83} Explicit declarations of "=" are now permitted for any combination of parameter and result types. 9.b Explicit declarations of "/=" are now permitted, so long as the result type is not Boolean. 6.7 Null Procedures 1/2 {AI95-00348-01} A null_procedure_declaration provides a shorthand to declare a procedure with an empty body. Syntax 2/2 {AI95-00348-01} null_procedure_declaration ::= [overriding_indicator] procedure_specification is null; Static Semantics 3/2 {AI95-00348-01} A null_procedure_declaration declares a null procedure.{null procedure} {procedure (null)} A completion is not allowed for a null_procedure_declaration. 3.a/2 Reason: There are no null functions because the return value has to be constructed somehow; a function that always raises Program_Error doesn't seem very useful or worth the complication. Dynamic Semantics 4/2 {AI95-00348-01} The execution of a null procedure is invoked by a subprogram call. For the execution of a subprogram call on a null procedure, the execution of the subprogram_body has no effect. 4.a/2 Ramification: Thus, a null procedure is equivalent to the body 4.b/2 begin null; end; 4.c/2 with the exception that a null procedure can be used in place of a procedure specification. 5/2 {AI95-00348-01} {elaboration (null_procedure_declaration) [partial]} The elaboration of a null_procedure_declaration has no effect. Examples 6/2 {AI95-00433-01} procedure Simplify(Expr : in out Expression) is null; -- see 3.9 -- By default, Simplify does nothing, but it may be overridden in extensions of Expression Extensions to Ada 95 6.a/2 {AI95-00348-01} {extensions to Ada 95} Null procedures are new.