6 Subprograms 1 A subprogram is a program unit or intrinsic operation whose execution is invoked by a subprogram call. There are two forms of subprogram: procedures and functions. A procedure call is a statement; a function call is an expression and returns a value. The definition of a subprogram can be given in two parts: a subprogram declaration defining its interface, and a subprogram_body defining its execution. [Operators and enumeration literals are functions.] 1.a To be honest: A function call is an expression, but more specifically it is a name. 1.b/2 Glossary entry: A subprogram is a section of a program that can be executed in various contexts. It is invoked by a subprogram call that may qualify the effect of the subprogram through the passing of parameters. There are two forms of subprograms: functions, which return values, and procedures, which do not. 1.c/2 Glossary entry: A function is a form of subprogram that returns a result and can be called as part of an expression. 1.d/2 Glossary entry: A procedure is a form of subprogram that does not return a result and can only be called by a statement. 2/3 {AI05-0299-1} A callable entity is a subprogram or entry (see Section 9). A callable entity is invoked by a call; that is, a subprogram call or entry call. A callable construct is a construct that defines the action of a call upon a callable entity: a subprogram_body, entry_body, or accept_statement. 2.a Ramification: Note that "callable entity" includes predefined operators, enumeration literals, and abstract subprograms. " Call" includes calls of these things. They do not have callable constructs, since they don't have completions. 6.1 Subprogram Declarations 1 [A subprogram_declaration declares a procedure or function.] Syntax 2/3 {AI95-00218-03} {AI05-0183-1} subprogram_declaration ::= [overriding_indicator] subprogram_specification [aspect_specification]; 3/2 This paragraph was deleted.{AI95-00348-01} 4/2 {AI95-00348-01} subprogram_specification ::= procedure_specification | function_specification 4.1/2 {AI95-00348-01} procedure_specification ::= procedure defining_program_unit_name parameter_profile 4.2/2 {AI95-00348-01} function_specification ::= function defining_designator parameter_and_result_profile 5 designator ::= [parent_unit_name . ]identifier | operator_symbol 6 defining_designator ::= defining_program_unit_name | defining_operator_symbol 7 defining_program_unit_name ::= [parent_unit_name . ]defining_identifier 8 [The optional parent_unit_name is only allowed for library units (see 10.1.1).] 9 operator_symbol ::= string_literal 10/3 {AI95-00395-01} {AI05-0299-1} The sequence of characters in an operator_symbol shall form a reserved word, a delimiter, or compound delimiter that corresponds to an operator belonging to one of the six categories of operators defined in subclause 4.5. 10.a/3 Reason: {AI95-00395-01} {AI05-0090-1} The "sequence of characters" of the string literal of the operator is a technical term (see 2.6), and does not include the surrounding quote characters. As defined in 2.2, lexical elements are "formed" from a sequence of characters. Spaces are not allowed, and upper and lower case is not significant. 11 defining_operator_symbol ::= operator_symbol 12 parameter_profile ::= [formal_part] 13/2 {AI95-00231-01} {AI95-00318-02} parameter_and_result_profile ::= [formal_part] return [null_exclusion] subtype_mark | [formal_part] return access_definition 14 formal_part ::= (parameter_specification {; parameter_specification}) 15/3 {AI95-00231-01} {AI05-0142-4} parameter_specification ::= defining_identifier_list : [aliased] mode [null_exclusion ] subtype_mark [:= default_expression] | defining_identifier_list : access_definition [:= default_expression] 16 mode ::= [in] | in out | out Name Resolution Rules 17 A formal parameter is an object [directly visible within a subprogram_body] that represents the actual parameter passed to the subprogram in a call; it is declared by a parameter_specification. For a formal parameter, the expected type for its default_expression, if any, is that of the formal parameter. Legality Rules 18/3 {AI05-0143-1} The parameter mode of a formal parameter conveys the direction of information transfer with the actual parameter: in, in out, or out. Mode in is the default, and is the mode of a parameter defined by an access_definition. 18.a/3 This paragraph was deleted.{AI05-0143-1} 19 A default_expression is only allowed in a parameter_specification for a formal parameter of mode in. 20/3 {AI95-00348-01} {AI05-0177-1} {AI05-0229-1} A subprogram_declaration or a generic_subprogram_declaration requires a completion [unless the Import aspect (see B.1) is True for the declaration; the completion shall be a body or a renaming_declaration (see 8.5)]. [A completion is not allowed for an abstract_subprogram_declaration (see 3.9.3), a null_procedure_declaration (see 6.7), or an expression_function_declaration (see 6.8).] 20.a/3 Ramification: {AI95-00348-01} {AI05-0177-1} Abstract subprograms , null procedures, and expression functions are not declared by subprogram_declarations, and so do not require completion (although the latter two can be completions). Protected subprograms are declared by subprogram_declarations, and so require completion. Note that an abstract subprogram is a subprogram, a null procedure is a subprogram, an expression function is a subprogram, and a protected subprogram is a subprogram, but a generic subprogram is not a subprogram. 20.b/3 Proof: {AI05-0229-1} When the Import aspect is True for any entity, no completion is allowed (see B.1). 21 A name that denotes a formal parameter is not allowed within the formal_part in which it is declared, nor within the formal_part of a corresponding body or accept_statement. 21.a Ramification: By contrast, generic_formal_parameter_declarations are visible to subsequent declarations in the same generic_formal_part. Static Semantics 22 The profile of (a view of) a callable entity is either a parameter_profile or parameter_and_result_profile[; it embodies information about the interface to that entity - for example, the profile includes information about parameters passed to the callable entity. All callable entities have a profile - enumeration literals, other subprograms, and entries. An access-to-subprogram type has a designated profile.] Associated with a profile is a calling convention. A subprogram_declaration declares a procedure or a function, as indicated by the initial reserved word, with name and profile as given by its specification. 23/2 {AI95-00231-01} {AI95-00318-02} The nominal subtype of a formal parameter is the subtype determined by the optional null_exclusion and the subtype_mark, or defined by the access_definition, in the parameter_specification. The nominal subtype of a function result is the subtype determined by the optional null_exclusion and the subtype_mark, or defined by the access_definition, in the parameter_and_result_profile. 23.1/3 {AI05-0142-4} An explicitly aliased parameter is a formal parameter whose parameter_specification includes the reserved word aliased. 24/2 {AI95-00231-01} {AI95-00254-01} {AI95-00318-02} An access parameter is a formal in parameter specified by an access_definition. An access result type is a function result type specified by an access_definition. An access parameter or result type is of an anonymous access type (see 3.10). [Access parameters of an access-to-object type allow dispatching calls to be controlled by access values. Access parameters of an access-to-subprogram type permit calls to subprograms passed as parameters irrespective of their accessibility level.] 24.a/2 Discussion: {AI95-00318-02} Access result types have normal accessibility and thus don't have any special properties worth noting here. 25 The subtypes of a profile are: 26 * For any non-access parameters, the nominal subtype of the parameter. 27/2 * {AI95-00254-01} For any access parameters of an access-to-object type, the designated subtype of the parameter type. 27.1/3 * {AI95-00254-01} {AI05-0164-1} For any access parameters of an access-to-subprogram type, the subtypes of the designated profile of the parameter type. 28/2 * {AI95-00231-01} {AI95-00318-02} For any non-access result, the nominal subtype of the function result. 28.1/2 * {AI95-00318-02} For any access result type of an access-to-object type, the designated subtype of the result type. 28.2/3 * {AI95-00318-02} {AI05-0164-1} For any access result type of an access-to-subprogram type, the subtypes of the designated profile of the result type. 29 [ The types of a profile are the types of those subtypes.] 30/3 {AI95-00348-01} {AI05-0177-1} [A subprogram declared by an abstract_subprogram_declaration is abstract; a subprogram declared by a subprogram_declaration is not. See 3.9.3, "Abstract Types and Subprograms". Similarly, a procedure declared by a null_procedure_declaration is a null procedure; a procedure declared by a subprogram_declaration is not. See 6.7 , "Null Procedures". Finally, a function declared by an expression_function_declaration is an expression function; a function declared by a subprogram_declaration is not. See 6.8, "Expression Functions".] 30.1/2 {AI95-00218-03} [An overriding_indicator is used to indicate whether overriding is intended. See 8.3.1, "Overriding Indicators".] Dynamic Semantics 31/2 {AI95-00348-01} The elaboration of a subprogram_declaration has no effect. NOTES 32 1 A parameter_specification with several identifiers is equivalent to a sequence of single parameter_specifications, as explained in 3.3. 33 2 Abstract subprograms do not have bodies, and cannot be used in a nondispatching call (see 3.9.3, "Abstract Types and Subprograms"). 34 3 The evaluation of default_expressions is caused by certain calls, as described in 6.4.1. They are not evaluated during the elaboration of the subprogram declaration. 35 4 Subprograms can be called recursively and can be called concurrently from multiple tasks. Examples 36 Examples of subprogram declarations: 37 procedure Traverse_Tree; procedure Increment(X : in out Integer); procedure Right_Indent(Margin : out Line_Size); -- see 3.5.4 procedure Switch(From, To : in out Link); -- see 3.10.1 38 function Random return Probability; -- see 3.5.7 39/4 {AI12-0056-1} function Min_Cell(X : Link) return Cell; -- see 3.10.1 function Next_Frame(K : Positive) return Frame; -- see 3.10 function Dot_Product(Left, Right : Vector) return Real; -- see 3.6 function Find(B : aliased in out Barrel; Key : String) return Real; -- see 4.1.5 40 function "*"(Left, Right : Matrix) return Matrix; -- see 3.6 41 Examples of in parameters with default expressions: 42 procedure Print_Header(Pages : in Natural; Header : in Line := (1 .. Line'Last => ' '); -- see 3.6 Center : in Boolean := True); Extensions to Ada 83 42.a The syntax for abstract_subprogram_declaration is added. The syntax for parameter_specification is revised to allow for access parameters (see 3.10) 42.b/3 {AI05-0299-1} Program units that are library units may have a parent_unit_name to indicate the parent of a child (see 10.1.1). Wording Changes from Ada 83 42.c We have incorporated the rules from RM83-6.5, "Function Subprograms" here and in 6.3, "Subprogram Bodies" 42.d We have incorporated the definitions of RM83-6.6, "Parameter and Result Type Profile - Overloading of Subprograms" here. 42.e The syntax rule for defining_operator_symbol is new. It is used for the defining occurrence of an operator_symbol, analogously to defining_identifier. Usage occurrences use the direct_name or selector_name syntactic categories. The syntax rules for defining_designator and defining_program_unit_name are new. Extensions to Ada 95 42.f/2 {AI95-00218-03} Subprograms now allow overriding_indicators for better error checking of overriding. 42.g/2 {AI95-00231-01} An optional null_exclusion can be used in a formal parameter declaration. Similarly, an optional null_exclusion can be used in a function result. 42.h/2 {AI95-00318-02} The return type of a function can be an anonymous access type. Wording Changes from Ada 95 42.i/2 {AI95-00254-01} A description of the purpose of anonymous access-to-subprogram parameters and the definition of the profile of subprograms containing them was added. 42.j/2 {AI95-00348-01} Split the production for subprogram_specification in order to make the declaration of null procedures (see 6.7) easier. 42.k/2 {AI95-00348-01} Moved the Syntax and Dynamic Semantics for abstract_subprogram_declaration to 3.9.3, so that the syntax and semantics are together. This also keeps abstract and null subprograms similar. 42.l/2 {AI95-00395-01} Revised to allow other_format characters in operator_symbols in the same way as the underlying constructs. Extensions to Ada 2005 42.m/3 {AI05-0142-4} Parameters can now be explicitly aliased, allowing parts of function results to designate parameters and forcing by-reference parameter passing. 42.n/3 {AI05-0143-1} The parameters of a function can now have any mode. 42.o/3 {AI05-0183-1} An optional aspect_specification can be used in a subprogram_declaration. This is described in 13.1.1. Wording Changes from Ada 2005 42.p/3 {AI05-0177-1} Added expression functions (see 6.8) to the wording. 6.1.1 Preconditions and Postconditions 1/4 {AI05-0145-2} {AI05-0247-1} {AI12-0045-1} For a noninstance subprogram, a generic subprogram, or an entry, the following language-defined aspects may be specified with an aspect_specification (see 13.1.1): 1.a/4 Ramification: {AI12-0045-1} "Noninstance subprogram" excludes a subprogram that is an instance of a generic subprogram. In that case, the aspects should be specified on the generic subprogram. If preconditions or postconditions need to be added to an instance of a generic subprogram, it can be accomplished by creating a separate subprogram specification and then completing that specification with a renames-as-body of the instance. 2/3 Pre This aspect specifies a specific precondition for a callable entity; it shall be specified by an expression, called a specific precondition expression. If not specified for an entity, the specific precondition expression for the entity is the enumeration literal True. 2.a/3 To be honest: In this and the following rules, we are talking about the enumeration literal True declared in package Standard (see A.1), and not some other value or identifier True. That matters as some rules depend on full conformance of these expressions, which depends on the specific declarations involved. 2.b/3 Aspect Description for Pre: Precondition; a condition that must hold true before a call. 3/3 {AI05-0254-1} {AI05-0262-1} Pre'Class This aspect specifies a class-wide precondition for an operation of a tagged type and its descendants; it shall be specified by an expression, called a class-wide precondition expression. If not specified for an entity, then if no other class-wide precondition applies to the entity, the class-wide precondition expression for the entity is the enumeration literal True. 3.a/3 Ramification: {AI05-0254-1} If other class-wide preconditions apply to the entity and no class-wide precondition is specified, no class-wide precondition is defined for the entity; of course, the class-wide preconditions (of ancestors) that apply are still going to be checked. We need subprograms that don't have ancestors and don't specify a class-wide precondition to have a class-wide precondition of True, so that adding such a precondition to a descendant has no effect (necessary as a dispatching call through the root routine would not check any precondition). 3.b/3 Aspect Description for Pre'Class: Precondition inherited on type derivation. 4/3 Post This aspect specifies a specific postcondition for a callable entity; it shall be specified by an expression, called a specific postcondition expression. If not specified for an entity, the specific postcondition expression for the entity is the enumeration literal True. 4.a/3 Aspect Description for Post: Postcondition; a condition that must hold true after a call. 5/3 {AI05-0262-1} Post'Class This aspect specifies a class-wide postcondition for an operation of a tagged type and its descendants; it shall be specified by an expression, called a class-wide postcondition expression. If not specified for an entity, the class-wide postcondition expression for the entity is the enumeration literal True. 5.a/3 Aspect Description for Post'Class: Postcondition inherited on type derivation. Name Resolution Rules 6/3 {AI05-0145-2} The expected type for a precondition or postcondition expression is any boolean type. 7/4 {AI05-0145-2} {AI05-0262-1} {AI12-0113-1} {AI12-0159-1} Within the expression for a Pre'Class or Post'Class aspect for a primitive subprogram S of a tagged type T, a name that denotes a formal parameter (or S'Result) of type T is interpreted as though it had a (notional) type NT that is a formal derived type whose ancestor type is T, with directly visible primitive operations. Similarly, a name that denotes a formal access parameter (or S'Result) of type access-to-T is interpreted as having type access-to-NT. [The result of this interpretation is that the only operations that can be applied to such names are those defined for such a formal derived type.] 7.a/4 Reason: {AI12-0159-1} This ensures that the expression is well-defined for any primitive subprogram of a type descended from T. 8/3 {AI05-0145-2} {AI05-0264-1} For an attribute_reference with attribute_designator Old, if the attribute reference has an expected type or shall resolve to a given type, the same applies to the prefix; otherwise, the prefix shall be resolved independently of context. Legality Rules 9/3 {AI05-0145-2} {AI05-0230-1} The Pre or Post aspect shall not be specified for an abstract subprogram or a null procedure. [Only the Pre'Class and Post'Class aspects may be specified for such a subprogram.] 9.a/3 Discussion: {AI05-0183-1} Pre'Class and Post'Class can only be specified on primitive routines of tagged types, by a blanket rule found in 13.1.1. 10/3 {AI05-0247-1} {AI05-0254-1} If a type T has an implicitly declared subprogram P inherited from a parent type T1 and a homograph (see 8.3) of P from a progenitor type T2, and 11/3 * the corresponding primitive subprogram P1 of type T1 is neither null nor abstract; and 12/3 * the class-wide precondition expression True does not apply to P1 (implicitly or explicitly); and 13/3 * there is a class-wide precondition expression that applies to the corresponding primitive subprogram P2 of T2 that does not fully conform to any class-wide precondition expression that applies to P1, 14/3 {AI05-0247-1} {AI05-0254-1} then: 15/3 * If the type T is abstract, the implicitly declared subprogram P is abstract. 16/3 * Otherwise, the subprogram P requires overriding and shall be overridden with a nonabstract subprogram. 16.a/3 Discussion: We use the term "requires overriding" here so that this rule is taken into account when calculating visibility in 8.3; otherwise we would have a mess when this routine is overridden. 16.b/3 Reason: Such an inherited subprogram would necessarily violate the Liskov Substitutability Principle (LSP) if called via a dispatching call from an ancestor other than the one that provides the called body. In such a case, the class-wide precondition of the actual body is stronger than the class-wide precondition of the ancestor. If we did not enforce that precondition for the body, the body could be called when the precondition it knows about is False - such "counterfeiting" of preconditions has to be avoided. But enforcing the precondition violates LSP. We do not want the language to be implicitly creating bodies that violate LSP; the programmer can still write an explicit body that calls the appropriate parent subprogram. In that case, the violation of LSP is explicitly in the code and obvious to code reviewers (both human and automated). 16.c/3 We have to say that the subprogram is abstract for an abstract type in this case, so that the next concrete type has to override it for the reasons above. Otherwise, inserting an extra level of abstract types would eliminate the requirement to override (as there is only one declared operation for the concrete type), and that would be bad for the reasons given above. 16.d/3 Ramification: This requires the set of class-wide preconditions that apply to the interface routine to be strictly stronger than those that apply to the concrete routine. Since full conformance requires each name to denote the same declaration, it is unlikely that independently declared preconditions would conform. This rule does allow "diamond inheritance" of preconditions, and of course no preconditions at all match. 16.e/3 We considered adopting a rule that would allow examples where the expressions would conform after all inheritance has been applied, but this is complex and is not likely to be common in practice. Since the penalty here is just that an explicit overriding is required, the complexity is too much. 17/3 {AI05-0247-1} If a renaming of a subprogram or entry S1 overrides an inherited subprogram S2, then the overriding is illegal unless each class-wide precondition expression that applies to S1 fully conforms to some class-wide precondition expression that applies to S2 and each class-wide precondition expression that applies to S2 fully conforms to some class-wide precondition expression that applies to S1. 17.a/3 Reason: Such an overriding subprogram would violate LSP, as the precondition of S1 would usually be different (and thus stronger) than the one known to a dispatching call through an ancestor routine of S2. This is always OK if the preconditions match, so we always allow that. 17.b/3 Ramification: This only applies to primitives of tagged types; other routines cannot have class-wide preconditions. 17.1/4 {AI12-0131-1} Pre'Class shall not be specified for an overriding primitive subprogram of a tagged type T unless the Pre'Class aspect is specified for the corresponding primitive subprogram of some ancestor of T. 17.c/4 Reason: Any such Pre'Class will have no effect, as it will be ored with True. As such, it is highly misleading for readers, especially for those who are determining the assumptions that can be made in the body of the primitive subprogram. Note that in this case there is nothing explicit that might indicate that the class-wide precondition is ineffective. This rule does not prevent explicitly writing an ineffective class-wide precondition (for instance, if the parent subprogram has explicitly specified a precondition of True). 17.2/4 {AI12-0131-1} In addition to the places where Legality Rules normally apply (see 12.3), these rules also apply in the private part of an instance of a generic unit. Static Semantics 18/4 {AI05-0145-2} {AI12-0113-1} {AI12-0131-1} If a Pre'Class or Post'Class aspect is specified for a primitive subprogram S of a tagged type T, or such an aspect defaults to True, then a corresponding expression also applies to the corresponding primitive subprogram S of each descendant of T. The corresponding expression is constructed from the associated expression as follows: 18.a/4 Ramification: A Pre'Class defaults to True only if no class-wide preconditions are inherited for the subprogram. The same is true for Post'Class. 18.b/4 Reason: We have to inherit precondition expressions that default to True, so that later overridings don't strengthen the precondition (a violation of LSP). We do the same for postconditions for consistency. 18.1/4 * {AI12-0113-1} References to formal parameters of S (or to S itself) are replaced with references to the corresponding formal parameters of the corresponding inherited or overriding subprogram S (or to the corresponding subprogram S itself). 18.c/4 Reason: We have to define the corresponding expression this way as overriding routines are only required to be subtype conformant; in particular, the parameter names can be different. So we have to talk about corresponding parameters without mentioning any names. 18.2/4 {AI12-0113-1} The primitive subprogram S is illegal if it is not abstract and the corresponding expression for a Pre'Class or Post'Class aspect would be illegal. 18.d/4 Ramification: This can happen, for instance, if one of the subprograms called in the corresponding expression is abstract. We made the rule general so that we don't have to worry about exactly which cases can cause this to happen, both now and in the future. 18.e/4 Reason: We allow illegal corresponding expressions on abstract subprograms as they could never be evaluated, and we need to allow such expressions to contain calls to abstract subprograms. 19/3 {AI05-0145-2} {AI05-0262-1} {AI05-0290-1} If performing checks is required by the Pre, Pre'Class, Post, or Post'Class assertion policies (see 11.4.2) in effect at the point of a corresponding aspect specification applicable to a given subprogram or entry, then the respective precondition or postcondition expressions are considered enabled. 19.a/3 Ramification: {AI05-0290-1} If a class-wide precondition or postcondition expression is enabled, it remains enabled when inherited by an overriding subprogram, even if the policy in effect is Ignore for the inheriting subprogram. 20/3 {AI05-0273-1} An expression is potentially unevaluated if it occurs within: 21/3 * any part of an if_expression other than the first condition; 22/3 * a dependent_expression of a case_expression; 22.1/4 * {AI12-0032-1} a predicate of a quantified_expression; 23/3 * the right operand of a short-circuit control form; or 24/3 * a membership_choice other than the first of a membership operation. 25/3 {AI05-0145-2} For a prefix X that denotes an object of a nonlimited type, the following attribute is defined: 26/4 X'Old {AI05-0145-2} {AI05-0262-1} {AI05-0273-1} {AI12-0032-1} Each X'Old in a postcondition expression that is enabled denotes a constant that is implicitly declared at the beginning of the subprogram body, entry body, or accept statement. 26.1/4 {AI12-0032-1} {AI12-0159-1} The implicitly declared entity denoted by each occurrence of X'Old is declared as follows: 26.2/4 * If X is of an anonymous access type defined by an access_definition A then 26.3/4 X'Old : constant A := X; 26.4/4 * If X is of a specific tagged type T then 26.5/4 anonymous : constant T'Class := T'Class(X); X'Old : T renames T(anonymous); 26.6/4 where the name X'Old denotes the object renaming. 26.a/4 Ramification: This means that the underlying tag associated with X'Old is that of X and not that of the nominal type of X. 26.7/4 * Otherwise 26.8/4 X'Old : constant S := X; 26.9/4 where S is the nominal subtype of X. This includes the case where the type of S is an anonymous array type or a universal type. 26.10/4 {AI12-0032-1} The nominal subtype of X'Old is as implied by the above definitions. The expected type of the prefix of an Old attribute is that of the attribute. Similarly, if an Old attribute shall resolve to be of some type, then the prefix of the attribute shall resolve to be of that type. 27/3 {AI05-0145-2} {AI05-0262-1} {AI05-0273-1} Reference to this attribute is only allowed within a postcondition expression. The prefix of an Old attribute_reference shall not contain a Result attribute_reference, nor an Old attribute_reference, nor a use of an entity declared within the postcondition expression but not within prefix itself (for example, the loop parameter of an enclosing quantified_expression). The prefix of an Old attribute_reference that is potentially unevaluated shall statically denote an entity. 27.a/3 Discussion: The prefix X can be any nonlimited object that obeys the syntax for prefix other than the few exceptions given above (discussed below). Useful cases are: the name of a formal parameter of mode [in] out, the name of a global variable updated by the subprogram, a function call passing those as parameters, a subcomponent of those things, etc. 27.b/3 A qualified expression can be used to make an arbitrary expression into a valid prefix, so T'(X + Y)'Old is legal, even though (X + Y)'Old is not. The value being saved here is the sum of X and Y (a function result is an object). Of course, in this case "+"(X, Y)'Old is also legal, but the qualified expression is arguably more readable. 27.c/3 Note that F(X)'Old and F(X'Old) are not necessarily equal. The former calls F(X) and saves that value for later use during the postcondition. The latter saves the value of X, and during the postcondition, passes that saved value to F. In most cases, the former is what one wants (but it is not always legal, see below). 27.d/4 {AI12-0032-1} If X has controlled parts, adjustment and finalization are implied by the implicit constant declaration. Similarly, the implicit constant declaration defines the accessibility level of X'Old. 27.e/3 If postconditions are disabled, we want the compiler to avoid any overhead associated with saving 'Old values. 27.f/3 'Old makes no sense for limited types, because its implementation involves copying. It might make semantic sense to allow build-in-place, but it's not worth the trouble. 27.g/3 Reason: {AI05-0273-1} Since the prefix is evaluated unconditionally when the subprogram is called, we cannot allow it to include values that do not exist at that time (like 'Result and loop parameters of quantified_expressions). We also do not allow it to include 'Old references, as those would be redundant (the entire prefix is evaluated when the subprogram is called), and allowing them would require some sort of order to the implicit constant declarations (because in A(I'Old)'Old, we surely would want the value of I'Old evaluated before the A(I'Old) is evaluated). 27.h/3 {AI05-0273-1} In addition, we only allow simple names as the prefix of the Old attribute if the attribute_reference might not be evaluated when the postcondition expression is evaluated. This is necessary because the Old prefixes have to be unconditionally evaluated when the subprogram is called; the compiler cannot in general know whether they will be needed in the postcondition expression. To see the problem, consider: 27.i/3 Table : array (1..10) of Integer := ... procedure Bar (I : in out Natural) with Post => I > 0 and then Table(I)'Old = 1; -- Illegal 27.j/3 In this example, the compiler cannot know the value of I when the subprogram returns (since the subprogram execution can change it), and thus it does not know whether Table(I)'Old will be needed then. Thus it has to always create an implicit constant and evaluate Table(I) when Bar is called (because not having the value when it is needed is not acceptable). But if I = 0 when the subprogram is called, that evaluation will raise Constraint_Error, and that will happen even if I is unchanged by the subprogram and the value of Table(I)'Old is not ultimately needed. It's easy to see how a similar problem could occur for a dereference of an access type. This would be mystifying (since the point of the short circuit is to eliminate this possibility, but it cannot do so). Therefore, we require the prefix of any Old attribute in such a context to statically denote an object, which eliminates anything that could change at during execution. 27.k/3 It is easy to work around most errors that occur because of this rule. Just move the 'Old to the outer object, before any indexing, dereferences, or components. (That does not work for function calls, however, nor does it work for array indexing if the index can change during the execution of the subprogram.) 27.l/4 Ramification: {AI12-0032-1} An accept statement for a task entry with enabled postconditions such as 27.m/4 accept E do statements exception handlers end; 27.n/4 behaves (at runtime) as follows: 27.o/4 accept E do declare declarations, if any, of 'Old constants begin begin statements exception handlers end; postcondition checks end; end; 27.p/4 {AI12-0032-1} Preconditions are checked by the caller before the rendezvous begins. Postcondition expressions might, of course, reference 'Old constants. 27.q/4 {AI12-0032-1} In the case of a protected operation with enabled postconditions, 'Old constant declarations (if any) are elaborated after the start of the protected action. Postcondition checks (which might reference these constants) are performed before the end of the protected action as described below. 28/3 {AI05-0145-2} For a prefix F that denotes a function declaration, the following attribute is defined: 29/3 F'Result {AI05-0145-2} {AI05-0262-1} Within a postcondition expression for function F, denotes the result object of the function. The type of this attribute is that of the function result except within a Post'Class postcondition expression for a function with a controlling result or with a controlling access result. For a controlling result, the type of the attribute is T'Class, where T is the function result type. For a controlling access result, the type of the attribute is an anonymous access type whose designated type is T'Class, where T is the designated type of the function result type. 30/3 {AI05-0262-1} Use of this attribute is allowed only within a postcondition expression for F. Dynamic Semantics 31/3 {AI05-0145-2} {AI05-0247-1} {AI05-0290-1} Upon a call of the subprogram or entry, after evaluating any actual parameters, precondition checks are performed as follows: 32/3 * The specific precondition check begins with the evaluation of the specific precondition expression that applies to the subprogram or entry, if it is enabled; if the expression evaluates to False, Assertions.Assertion_Error is raised; if the expression is not enabled, the check succeeds. 33/3 * The class-wide precondition check begins with the evaluation of any enabled class-wide precondition expressions that apply to the subprogram or entry. If and only if all the class-wide precondition expressions evaluate to False, Assertions.Assertion_Error is raised. 33.a/3 Ramification: The class-wide precondition expressions of the entity itself as well as those of any parent or progenitor operations are evaluated, as these expressions apply to the corresponding operations of all descendants. 33.b/3 Class-wide precondition checks are performed for all appropriate calls, but only enabled precondition expressions are evaluated. Thus, the check would be trivial if no precondition expressions are enabled. 34/3 {AI05-0145-2} {AI05-0247-1} {AI05-0254-1} {AI05-0269-1} The precondition checks are performed in an arbitrary order, and if any of the class-wide precondition expressions evaluate to True, it is not specified whether the other class-wide precondition expressions are evaluated. The precondition checks and any check for elaboration of the subprogram body are performed in an arbitrary order. It is not specified whether in a call on a protected operation, the checks are performed before or after starting the protected action. For an entry call, the checks are performed prior to checking whether the entry is open. 34.a/3 Reason: We need to explicitly allow short-circuiting of the evaluation of the class-wide precondition check if any expression fails, as it consists of multiple expressions; we don't need a similar permission for the specific precondition check as it consists only of a single expression. Nothing is evaluated for the call after a check fails, as the failed check propagates an exception. 35/3 {AI05-0145-2} {AI05-0247-1} {AI05-0254-1} {AI05-0262-1} {AI05-0290-1} Upon successful return from a call of the subprogram or entry, prior to copying back any by-copy in out or out parameters, the postcondition check is performed. This consists of the evaluation of any enabled specific and class-wide postcondition expressions that apply to the subprogram or entry. If any of the postcondition expressions evaluate to False, then Assertions.Assertion_Error is raised. The postcondition expressions are evaluated in an arbitrary order, and if any postcondition expression evaluates to False, it is not specified whether any other postcondition expressions are evaluated. The postcondition check, and any constraint or predicate checks associated with in out or out parameters are performed in an arbitrary order. 35.a/3 Ramification: The class-wide postcondition expressions of the entity itself as well as those of any parent or progenitor operations are evaluated, as these apply to all descendants; in contrast, only the specific postcondition of the entity applies. Postconditions can always be evaluated inside the invoked body. 35.1/4 {AI12-0032-1} For a call to a task entry, the postcondition check is performed before the end of the rendezvous; for a call to a protected operation, the postcondition check is performed before the end of the protected action of the call. The postcondition check for any call is performed before the finalization of any implicitly-declared constants associated (as described above) with Old attribute_references but after the finalization of any other entities whose accessibility level is that of the execution of the callable construct. 35.a.1/4 Reason: {AI12-0032-1} If a postcondition references the implicitly-declared constant associated with an Old attribute, the postcondition must be evaluated before the constant is finalized. One way to think of this is to imagine declaring a controlled object between any implicit "'Old" constant declarations and any explicit declarations, then performing postcondition checks during the finalization of this object. 36/3 {AI05-0145-2} {AI05-0262-1} If a precondition or postcondition check fails, the exception is raised at the point of the call[; the exception cannot be handled inside the called subprogram or entry]. Similarly, any exception raised by the evaluation of a precondition or postcondition expression is raised at the point of call. 37/4 {AI05-0145-2} {AI05-0247-1} {AI05-0254-1} {AI05-0262-1} {AI12-0113-1} {AI12-0159-1} For any call to a subprogram or entry S (including dispatching calls), the checks that are performed to verify specific precondition expressions and specific and class-wide postcondition expressions are determined by those for the subprogram or entry actually invoked. Note that the class-wide postcondition expressions verified by the postcondition check that is part of a call on a primitive subprogram of type T includes all class-wide postcondition expressions originating in any progenitor of T[, even if the primitive subprogram called is inherited from a type T1 and some of the postcondition expressions do not apply to the corresponding primitive subprogram of T1]. Any operations within a class-wide postcondition expression that were resolved as primitive operations of the (notional) formal derived type NT, are in the evaluation of the postcondition bound to the corresponding operations of the type identified by the controlling tag of the call on S.[ This applies to both dispatching and non-dispatching calls on S.] 37.a/3 Ramification: This applies to access-to-subprogram calls, dispatching calls, and to statically bound calls. We need this rule to cover statically bound calls as well, as specific pre- and postconditions are not inherited, but the subprogram might be. 37.b/3 For concrete subprograms, we require the original specific postcondition to be evaluated as well as the inherited class-wide postconditions in order that the semantics of an explicitly defined wrapper that does nothing but call the original subprogram is the same as that of an inherited subprogram. 37.c/3 Note that this rule does not apply to class-wide preconditions; they have their own rules mentioned below. 38/4 {AI05-0145-2} {AI05-0247-1} {AI05-0254-1} {AI12-0113-1} {AI12-0159-1} The class-wide precondition check for a call to a subprogram or entry S consists solely of checking the class-wide precondition expressions that apply to the denoted callable entity (not necessarily to the one that is invoked). Any operations within such an expression that were resolved as primitive operations of the (notional) formal derived type NT are in the evaluation of the precondition bound to the corresponding operations of the type identified by the controlling tag of the call on S.[ This applies to both dispatching and non-dispatching calls on S.] 38.a/3 Ramification: For a dispatching call, we are talking about the Pre'Class(es) that apply to the subprogram that the dispatching call is resolving to, not the Pre'Class(es) for the subprogram that is ultimately dispatched to. The class-wide precondition of the resolved call is necessarily the same or stronger than that of the invoked call. For a statically bound call, these are the same; for an access-to-subprogram, (which has no class-wide preconditions of its own), we check the class-wide preconditions of the invoked routine. 38.b/3 Implementation Note: These rules imply that logically, class-wide preconditions of routines must be checked at the point of call (other than for access-to-subprogram calls, which must be checked in the body, probably using a wrapper). Specific preconditions that might be called with a dispatching call or via an access-to-subprogram value must be checked inside of the subprogram body. In contrast, the postcondition checks always need to be checked inside the body of the routine. Of course, an implementation can evaluate all of these at the point of call for statically bound calls if the implementation uses wrappers for dispatching bodies and for 'Access values. 38.c/3 There is no requirement for an implementation to generate special code for routines that are imported from outside of the Ada program. That's because there is a requirement on the programmer that the use of interfacing aspects do not violate Ada semantics (see B.1). That includes making pre- and postcondition checks. For instance, if the implementation expects routines to make their own postcondition checks in the body before returning, C code can be assumed to do this (even though that is highly unlikely). That's even though the formal definition of those checks is that they are evaluated at the call site. Note that pre- and postconditions can be very useful for verification tools (even if they aren't checked), because they tell the tool about the expectations on the foreign code that it most likely cannot analyze. 39/3 {AI05-0145-2} {AI05-0247-1} {AI05-0254-1} For a call via an access-to-subprogram value, all precondition and postcondition checks performed are determined by the subprogram or entry denoted by the prefix of the Access attribute reference that produced the value. NOTES 40/3 5 {AI05-0145-2} {AI05-0262-1} A precondition is checked just before the call. If another task can change any value that the precondition expression depends on, the precondition need not hold within the subprogram or entry body. Extensions to Ada 2005 40.a/3 {AI05-0145-2} {AI05-0230-1} {AI05-0247-1} {AI05-0254-1} {AI05-0262-1} {AI05-0273-1} {AI05-0274-1} Pre and Post aspects are new. Inconsistencies With Ada 2012 40.b/4 {AI12-0032-1} Corrigendum: The Old attribute is defined more carefully. This changes the nominal subtype and place of declaration of the attribute compared to the published Ada 2012 Standard. In extreme cases, this could change the runtime behavior of the attribute (for instance, the tag might be different). The changes are most likely going to prevent bugs by being more intuitive, but it is possible that a program that previously worked might fail. 40.c/4 {AI12-0113-1} {AI12-0159-1} Corrigendum: Eliminated unintentional redispatching from class-wide preconditions and postconditions. This means that a different body might be evaluated for a statically bound call to a routine that has a class-wide precondition or postcondition. The change means that the behavior of Pre and Pre'Class will be the same for a particular subprogram, and that the known behavior of the operations can be assumed within the body of that subprogram for Pre'Class. We expect that this change will primarily fix bugs, as it will make Pre'Class and Post'Class work more like expected. In the case where redispatching is desired, an explicit conversion to a class-wide type can be used. Incompatibilities With Ada 2012 40.d/4 {AI12-0045-1} Corrigendum: Precondition and postcondition aspects cannot be specified on instances of generic subprograms (they should be specified on the generic subprogram instead). This was (unintentionally) allowed by the Ada 2012 standard. These are not be allowed on instances as there is no corresponding way to add preconditions and postconditions to subprograms declared within the instance of a generic package. Therefore, allowing specification on a subprogram instance could present a maintenance problem in the future if the entity needs to be converted to a generic package (a common conversion). 40.e/4 {AI12-0131-1} Corrigendum: Pre'Class is no longer allowed to be specified for an overriding primitive subprogram unless there are also inherited class-wide precondittions. This incompatibility prevents cases where the explicit Pre'Class is counterfeited by an implicit class-wide precondition of True. This rule should catch more bugs than it creates; the programmer should have written Pre rather than Pre'Class in this case (or written Pre'Class on the original subprogram, not an overriding). Note that this incompatibility eliminates what otherwise would be an inconsistency with original Ada 2012, where precondition checks that would have previously been made for a statically bound call would no longer be made. That dynamic change was necessary to eliminate cases where the evaluated class-wide precondition on a dispatching call would have been weaker than the class-wide precondition of a statically bound call. (The original Ada 2012 violated the LSP semantics that class-wide preconditions were intended to model. 6.2 Formal Parameter Modes 1 [A parameter_specification declares a formal parameter of mode in, in out, or out.] Static Semantics 2 A parameter is passed either by copy or by reference. [When a parameter is passed by copy, the formal parameter denotes a separate object from the actual parameter, and any information transfer between the two occurs only before and after executing the subprogram. When a parameter is passed by reference, the formal parameter denotes (a view of) the object denoted by the actual parameter; reads and updates of the formal parameter directly reference the actual parameter object.] 3/3 {AI05-0142-4} {AI05-0262-1} A type is a by-copy type if it is an elementary type, or if it is a descendant of a private type whose full type is a by-copy type. A parameter of a by-copy type is passed by copy, unless the formal parameter is explicitly aliased. 4 A type is a by-reference type if it is a descendant of one of the following: 5 * a tagged type; 6 * a task or protected type; 7/3 * {AI05-0096-1} an explicitly limited record type; 7.a/3 This paragraph was deleted.{AI05-0096-1} 8 * a composite type with a subcomponent of a by-reference type; 9 * a private type whose full type is a by-reference type. 10/4 {AI05-0142-4} {AI05-0188-1} {AI12-0027-1} A parameter of a by-reference type is passed by reference, as is an explicitly aliased parameter of any type. Each value of a by-reference type has an associated object. For a parenthesized expression, qualified_expression, or view conversion, this object is the one associated with the operand. For a value conversion, the associated object is the anonymous result object if such an object is created (see 4.6); otherwise it is the associated object of the operand. For a conditional_expression, this object is the one associated with the evaluated dependent_expression. 10.a Ramification: By-reference parameter passing makes sense only if there is an object to reference; hence, we define such an object for each case. 10.b Since tagged types are by-reference types, this implies that every value of a tagged type has an associated object. This simplifies things, because we can define the tag to be a property of the object, and not of the value of the object, which makes it clearer that object tags never change. 10.c We considered simplifying things even more by making every value (and therefore every expression) have an associated object. After all, there is little semantic difference between a constant object and a value. However, this would cause problems for untagged types. In particular, we would have to do a constraint check on every read of a type conversion (or a renaming thereof) in certain cases. 10.d/2 {AI95-00318-02} We do not want this definition to depend on the view of the type; privateness is essentially ignored for this definition. Otherwise, things would be confusing (does the rule apply at the call site, at the site of the declaration of the subprogram, at the site of the return statement?), and requiring different calls to use different mechanisms would be an implementation burden. 10.e C.6, "Shared Variable Control" says that a composite type with an atomic or volatile subcomponent is a by-reference type, among other things. 10.f Every value of a limited by-reference type is the value of one and only one limited object. The associated object of a value of a limited by-reference type is the object whose value it represents. Two values of a limited by-reference type are the same if and only if they represent the value of the same object. 10.g We say "by-reference" above because these statements are not always true for limited private types whose underlying type is nonlimited (unfortunately). 11/3 {AI05-0240-1} For other parameters, it is unspecified whether the parameter is passed by copy or by reference. 11.a/3 Discussion: {AI05-0005-1} There is no need to incorporate the discussion of AI83-00178, which requires pass-by-copy for certain kinds of actual parameters, while allowing pass-by-reference for others. This is because we explicitly indicate that a function creates an anonymous constant object for its result (see 6.5). We also provide a special dispensation for instances of Unchecked_Conversion to return by reference (see 13.9). Bounded (Run-Time) Errors 12/3 {AI05-0240-1} If one name denotes a part of a formal parameter, and a second name denotes a part of a distinct formal parameter or an object that is not part of a formal parameter, then the two names are considered distinct access paths. If an object is of a type for which the parameter passing mechanism is not specified and is not an explicitly aliased parameter, then it is a bounded error to assign to the object via one access path, and then read the value of the object via a distinct access path, unless the first access path denotes a part of a formal parameter that no longer exists at the point of the second access [(due to leaving the corresponding callable construct).] The possible consequences are that Program_Error is raised, or the newly assigned value is read, or some old value of the object is read. 12.a Discussion: For example, if we call "P(X => Global_Variable, Y => Global_Variable)", then within P, the names "X", "Y", and " Global_Variable" are all distinct access paths. If Global_Variable's type is neither pass-by-copy nor pass-by-reference, then it is a bounded error to assign to Global_Variable and then read X or Y, since the language does not specify whether the old or the new value would be read. On the other hand, if Global_Variable's type is pass-by-copy, then the old value would always be read, and there is no error. Similarly, if Global_Variable's type is defined by the language to be pass-by-reference, then the new value would always be read, and again there is no error. 12.b Reason: We are saying assign here, not update, because updating any subcomponent is considered to update the enclosing object. 12.c The "still exists" part is so that a read after the subprogram returns is OK. 12.d If the parameter is of a by-copy type, then there is no issue here - the formal is not a view of the actual. If the parameter is of a by-reference type, then the programmer may depend on updates through one access path being visible through some other access path, just as if the parameter were of an access type. 12.e Implementation Note: The implementation can keep a copy in a register of a parameter whose parameter-passing mechanism is not specified. If a different access path is used to update the object (creating a bounded error situation), then the implementation can still use the value of the register, even though the in-memory version of the object has been changed. However, to keep the error properly bounded, if the implementation chooses to read the in-memory version, it has to be consistent -- it cannot then assume that something it has proven about the register is true of the memory location. For example, suppose the formal parameter is L, the value of L(6) is now in a register, and L(6) is used in an indexed_component as in "A(L(6)) := 99;", where A has bounds 1..3. If the implementation can prove that the value for L(6) in the register is in the range 1..3, then it need not perform the constraint check if it uses the register value. However, if the memory value of L(6) has been changed to 4, and the implementation uses that memory value, then it had better not alter memory outside of A. 12.f Note that the rule allows the implementation to pass a parameter by reference and then keep just part of it in a register, or, equivalently, to pass part of the parameter by reference and another part by copy. 12.g Reason: We do not want to go so far as to say that the mere presence of aliasing is wrong. We wish to be able to write the following sorts of things in standard Ada: 12.h procedure Move ( Source : in String; Target : out String; Drop : in Truncation := Error; Justify : in Alignment := Left; Pad : in Character := Space); -- Copies elements from Source to Target (safely if they overlap) 12.i This is from the standard string handling package. It would be embarrassing if this couldn't be written in Ada! 12.j The "then" before "read" in the rule implies that the implementation can move a read to an earlier place in the code, but not to a later place after a potentially aliased assignment. Thus, if the subprogram reads one of its parameters into a local variable, and then updates another potentially aliased one, the local copy is safe - it is known to have the old value. For example, the above-mentioned Move subprogram can be implemented by copying Source into a local variable before assigning into Target. 12.k For an assignment_statement assigning one array parameter to another, the implementation has to check which direction to copy at run time, in general, in case the actual parameters are overlapping slices. For example: 12.l procedure Copy(X : in out String; Y: String) is begin X := Y; end Copy; 12.m It would be wrong for the compiler to assume that X and Y do not overlap (unless, of course, it can prove otherwise). NOTES 13/4 6 {AI12-0056-1} The mode of a formal parameter describes the direction of information transfer to or from the subprogram_body (see 6.1). 14 7 A formal parameter of mode in is a constant view (see 3.3); it cannot be updated within the subprogram_body. 15/4 8 {AI12-0056-1} A formal parameter of mode out might be uninitialized at the start of the subprogram_body (see 6.4.1). Extensions to Ada 83 15.a The value of an out parameter may be read. An out parameter is treated like a declared variable without an explicit initial expression. Wording Changes from Ada 83 15.b Discussion of copy-in for parts of out parameters is now covered in 6.4.1, "Parameter Associations". 15.c The concept of a by-reference type is new to Ada 95. 15.d We now cover in a general way in 3.7.2 the rule regarding erroneous execution when a discriminant is changed and one of the parameters depends on the discriminant. Wording Changes from Ada 2005 15.e/3 {AI05-0096-1} Correction: Corrected so that limited derived types are by-reference only if their parent is. 15.f/3 {AI05-0142-4} Defined that explicitly aliased parameters (see 6.1) are always passed by reference. Wording Changes from Ada 2012 15.g/4 {AI05-0027-1} Corrigendum: Corrected so that value conversions that are copies are the "associated object" for parameter passing of by-reference types. This can only happen if the conversion is between unrelated non-limited types, and it is necessary just so the correct object is defined. 6.3 Subprogram Bodies 1 [A subprogram_body specifies the execution of a subprogram.] Syntax 2/3 {AI95-00218-03} {AI05-0183-1} subprogram_body ::= [overriding_indicator] subprogram_specification [aspect_specification] is declarative_part begin handled_sequence_of_statements end [designator]; 3 If a designator appears at the end of a subprogram_body, it shall repeat the defining_designator of the subprogram_specification. Legality Rules 4 [In contrast to other bodies,] a subprogram_body need not be the completion of a previous declaration[, in which case the body declares the subprogram]. If the body is a completion, it shall be the completion of a subprogram_declaration or generic_subprogram_declaration. The profile of a subprogram_body that completes a declaration shall conform fully to that of the declaration. Static Semantics 5 A subprogram_body is considered a declaration. It can either complete a previous declaration, or itself be the initial declaration of the subprogram. Dynamic Semantics 6 The elaboration of a nongeneric subprogram_body has no other effect than to establish that the subprogram can from then on be called without failing the Elaboration_Check. 6.a Ramification: See 12.2 for elaboration of a generic body. Note that protected subprogram_bodies never get elaborated; the elaboration of the containing protected_body allows them to be called without failing the Elaboration_Check. 7 [The execution of a subprogram_body is invoked by a subprogram call.] For this execution the declarative_part is elaborated, and the handled_sequence_of_statements is then executed. Examples 8 Example of procedure body: 9 procedure Push(E : in Element_Type; S : in out Stack) is begin if S.Index = S.Size then raise Stack_Overflow; else S.Index := S.Index + 1; S.Space(S.Index) := E; end if; end Push; 10 Example of a function body: 11 function Dot_Product(Left, Right : Vector) return Real is Sum : Real := 0.0; begin Check(Left'First = Right'First and Left'Last = Right'Last); for J in Left'Range loop Sum := Sum + Left(J)*Right(J); end loop; return Sum; end Dot_Product; Extensions to Ada 83 11.a A renaming_declaration may be used instead of a subprogram_body. Wording Changes from Ada 83 11.b The syntax rule for subprogram_body now uses the syntactic category handled_sequence_of_statements. 11.c The declarative_part of a subprogram_body is now required; that doesn't make any real difference, because a declarative_part can be empty. 11.d We have incorporated some rules from RM83-6.5 here. 11.e RM83 forgot to restrict the definition of elaboration of a subprogram_body to nongenerics. Wording Changes from Ada 95 11.f/2 {AI95-00218-03} Overriding_indicator is added to subprogram_body. Extensions to Ada 2005 11.g/3 {AI05-0183-1} An optional aspect_specification can be used in a subprogram_body. This is described in 13.1.1. 6.3.1 Conformance Rules 1 [When subprogram profiles are given in more than one place, they are required to conform in one of four ways: type conformance, mode conformance, subtype conformance, or full conformance.] Static Semantics 2/1 {8652/0011} {AI95-00117-01} [As explained in B.1, "Interfacing Aspects", a convention can be specified for an entity.] Unless this International Standard states otherwise, the default convention of an entity is Ada. [For a callable entity or access-to-subprogram type, the convention is called the calling convention.] The following conventions are defined by the language: 3/3 * {AI05-0229-1} The default calling convention for any subprogram not listed below is Ada. [The Convention aspect may be specified to override the default calling convention (see B.1)]. 3.a Ramification: See also the rule about renamings-as-body in 8.5.4. 4 * The Intrinsic calling convention represents subprograms that are " built in" to the compiler. The default calling convention is Intrinsic for the following: 5 * an enumeration literal; 6 * a "/=" operator declared implicitly due to the declaration of "=" (see 6.6); 7 * any other implicitly declared subprogram unless it is a dispatching operation of a tagged type; 8 * an inherited subprogram of a generic formal tagged type with unknown discriminants; 8.a.1/1 Reason: Consider: 8.a.2/1 package P is type Root is tagged null record; procedure Proc(X: Root); end P; 8.a.3/1 generic type Formal(<>) is new Root with private; package G is ... end G; 8.a.4/1 package body G is ... X: Formal := ...; ... Proc(X); -- This is a dispatching call in Instance, because -- the actual type for Formal is class-wide. ... -- Proc'Access would be illegal here, because it is of -- convention Intrinsic, by the above rule. end G; 8.a.5/1 type Actual is new Root with ...; procedure Proc(X: Actual); package Instance is new G(Formal => Actual'Class); -- It is legal to pass in a class-wide actual, because Formal -- has unknown discriminants. 8.a.6/1 Within Instance, all calls to Proc will be dispatching calls, so Proc doesn't really exist in machine code, so we wish to avoid taking 'Access of it. This rule applies to those cases where the actual type might be class-wide, and makes these Intrinsic, thus forbidding 'Access. 9 * an attribute that is a subprogram; 10/2 * {AI95-00252-01} a subprogram declared immediately within a protected_body; 10.1/4 * {AI95-00252-01} {AI95-00407-01} {AI12-0107-1} any prefixed view of a subprogram (see 4.1.3) without synchronization kind (see 9.5) By_Entry or By_Protected_Procedure. 10.a/2 Reason: The profile of a prefixed view is different than the " real" profile of the subprogram (it doesn't have the first parameter), so we don't want to be able to take 'Access of it, as that would require generating a wrapper of some sort. 10.b/4 {AI12-0107-1} We except prefixed views that have synchronization kind By_Protected_Procedure so that they can be used with an access-to-protected-procedure type. These don't require special wrappers (this is the normal form for a protected subprogram call). The By_Entry part is just for consistency (there is no access-to-entry type in Ada). 11 [The Access attribute is not allowed for Intrinsic subprograms.] 11.a Ramification: The Intrinsic calling convention really represents any number of calling conventions at the machine code level; the compiler might have a different instruction sequence for each intrinsic. That's why the Access attribute is disallowed. We do not wish to require the implementation to generate an out of line body for an intrinsic. 11.b/3 {AI05-0229-1} Whenever we wish to disallow the Access attribute in order to ease implementation, we make the subprogram Intrinsic. Several language-defined subprograms have "with Convention => Intrinsic;". An implementation might actually implement this as "with Import => True, Convention => Intrinsic;", if there is really no body, and the implementation of the subprogram is built into the code generator. 11.c Subprograms declared in protected_bodies will generally have a special calling convention so as to pass along the identification of the current instance of the protected type. The convention is not protected since such local subprograms need not contain any "locking" logic since they are not callable via "external" calls; this rule prevents an access value designating such a subprogram from being passed outside the protected unit. 11.d The "implicitly declared subprogram" above refers to predefined operators (other than the "=" of a tagged type) and the inherited subprograms of untagged types. 12/4 * {AI12-0107-1} {AI12-0159-1} The default calling convention is protected for a protected subprogram, for a prefixed view of a subprogram with a synchronization kind of By_Protected_Procedure, and for an access-to-subprogram type with the reserved word protected in its definition. 13/4 * {AI12-0107-1} {AI12-0159-1} The default calling convention is entry for an entry and for a prefixed view of a subprogram with a synchronization kind of By_Entry. 13.1/3 * {AI95-00254-01} {AI95-00409-01} {AI05-0264-1} The calling convention for an anonymous access-to-subprogram parameter or anonymous access-to-subprogram result is protected if the reserved word protected appears in its definition; otherwise, it is the convention of the subprogram that contains the parameter. 13.a/2 Ramification: The calling convention for other anonymous access-to-subprogram types is Ada. 13.2/1 * {8652/0011} {AI95-00117-01} [If not specified above as Intrinsic, the calling convention for any inherited or overriding dispatching operation of a tagged type is that of the corresponding subprogram of the parent type.] The default calling convention for a new dispatching operation of a tagged type is the convention of the type. 13.a.1/1 Reason: The first rule is officially stated in 3.9.2. The second is intended to make interfacing to foreign OOP languages easier, by making the default be that the type and operations all have the same convention. 14/3 {AI05-0229-1} Of these four conventions, only Ada and Intrinsic are allowed as a convention_identifier in the specification of a Convention aspect. 14.a/3 Discussion: {AI05-0229-1} The names of the protected and entry calling conventions cannot be used in the specification of Convention. Note that protected and entry are reserved words. 15/2 {AI95-00409-01} Two profiles are type conformant if they have the same number of parameters, and both have a result if either does, and corresponding parameter and result types are the same, or, for access parameters or access results, corresponding designated types are the same, or corresponding designated profiles are type conformant. 15.a/2 Discussion: {AI95-00409-01} For anonymous access-to-object parameters, the designated types have to be the same for type conformance, not the access types, since in general each access parameter has its own anonymous access type, created when the subprogram is called. Of course, corresponding parameters have to be either both access parameters or both not access parameters. 15.b/2 {AI95-00409-01} Similarly, for anonymous access-to-subprogram parameters, the designated profiles of the types, not the types themselves, have to be conformant. 16/3 {AI95-00318-02} {AI95-00409-01} {AI05-0142-4} Two profiles are mode conformant if: 16.1/3 * {AI05-0142-4} {AI05-0262-1} they are type conformant; and 16.2/3 * {AI05-0142-4} corresponding parameters have identical modes and both or neither are explicitly aliased parameters; and 16.3/3 * {AI05-0207-1} for corresponding access parameters and any access result type, the designated subtypes statically match and either both or neither are access-to-constant, or the designated profiles are subtype conformant. 17/3 {AI05-0239-1} Two profiles are subtype conformant if they are mode conformant, corresponding subtypes of the profile statically match, and the associated calling conventions are the same. The profile of a generic formal subprogram is not subtype conformant with any other profile. 17.a Ramification: 18/3 {AI05-0134-1} {AI05-0262-1} Two profiles are fully conformant if they are subtype conformant, if they have access-to-subprogram results whose designated profiles are fully conformant, and for corresponding parameters: 18.1/3 * {AI05-0262-1} they have the same names; and 18.2/3 * {AI05-0046-1} both or neither have null_exclusions; and 18.3/3 * neither have default_expressions, or they both have default_expressions that are fully conformant with one another; and 18.4/3 * {AI05-0134-1} for access-to-subprogram parameters, the designated profiles are fully conformant. 18.a Ramification: Full conformance requires subtype conformance, which requires the same calling conventions. However, the calling convention of the declaration and body of a subprogram or entry are always the same by definition. 18.b/3 Reason: {AI05-0046-1} The part about null_exclusions is necessary to prevent controlling parameters from having different exclusions, as such a parameter is defined to exclude null whether or not an exclusion is given. 18.c/3 {AI05-0134-1} The parts about access-to-subprogram parameters and results is necessary to prevent such types from having different default_expressions in the specification and body of a subprogram. If that was allowed, it would be undefined which default_expression was used in a call of an access-to-subprogram parameter. 19 Two expressions are fully conformant if, [after replacing each use of an operator with the equivalent function_call:] 20 * each constituent construct of one corresponds to an instance of the same syntactic category in the other, except that an expanded name may correspond to a direct_name (or character_literal) or to a different expanded name in the other; and 20.1/4 * {AI12-0050-1} corresponding defining_identifiers occurring within the two expressions are the same; and 21/4 * {AI12-0050-1} each direct_name, character_literal, and selector_name that is not part of the prefix of an expanded name in one denotes the same declaration as the corresponding direct_name, character_literal, or selector_name in the other, or they denote corresponding declarations occurring within the two expressions; and 21.a Ramification: Note that it doesn't say "respectively" because a direct_name can correspond to a selector_name, and vice-versa, by the previous bullet. This rule allows the prefix of an expanded name to be removed, or replaced with a different prefix that denotes a renaming of the same entity. However, it does not allow a direct_name or selector_name to be replaced with one denoting a distinct renaming (except for direct_names and selector_names in prefixes of expanded names). Note that calls using operator notation are equivalent to calls using prefix notation. 21.b Given the following declarations: 21.c package A is function F(X : Integer := 1) return Boolean; end A; 21.c.1/3 {AI05-0005-1} with A; package B is package A_View renames A; function F_View(X : Integer := 9999) return Boolean renames A.F; end B; 21.d with A, B; use A, B; procedure Main is ... 21.e Within Main, the expressions "F", "A.F", "B.A_View.F", and " A_View.F" are all fully conformant with one another. However, " F" and "F_View" are not fully conformant. If they were, it would be bad news, since the two denoted views have different default_expressions. 21.f/4 Discussion: {AI12-0050-1} We talk about defining_identifiers and "corresponding declarations" because of the possibility of iterator_specifications occurring within the expressions; each iterator_specification is a separate declaration, which we need to allow, but we do want to require that the defining_identifiers are the same. 21.1/3 * {8652/0018} {AI95-00175-01} {AI05-0092-1} each attribute_designator in one is the same as the corresponding attribute_designator in the other; and 22 * each primary that is a literal in one has the same value as the corresponding literal in the other. 22.a Ramification: The literals may be written differently. 22.b Ramification: Note that the above definition makes full conformance a transitive relation. 23 Two known_discriminant_parts are fully conformant if they have the same number of discriminants, and discriminants in the same positions have the same names, statically matching subtypes, and default_expressions that are fully conformant with one another. 24 Two discrete_subtype_definitions are fully conformant if they are both subtype_indications or are both ranges, the subtype_marks (if any) denote the same subtype, and the corresponding simple_expressions of the ranges (if any) fully conform. 24.a Ramification: In the subtype_indication case, any ranges have to be corresponding; that is, two subtype_indications cannot conform unless both or neither has a range. 24.b Discussion: This definition is used in 9.5.2, " Entries and Accept Statements" for the conformance required between the discrete_subtype_definitions of an entry_declaration for a family of entries and the corresponding entry_index_specification of the entry_body. 24.1/2 {AI95-00345-01} {AI95-00397-01} The prefixed view profile of a subprogram is the profile obtained by omitting the first parameter of that subprogram. There is no prefixed view profile for a parameterless subprogram. For the purposes of defining subtype and mode conformance, the convention of a prefixed view profile is considered to match that of either an entry or a protected operation. 24.c/2 Discussion: This definition is used to define how primitive subprograms of interfaces match operations in task and protected type definitions (see 9.1 and 9.4). 24.d/2 Reason: The weird rule about conventions is pretty much required for synchronized interfaces to make any sense. There will be wrappers all over the place for interfaces anyway. Of course, this doesn't imply that entries have the same convention as protected operations. Implementation Permissions 25 An implementation may declare an operator declared in a language-defined library unit to be intrinsic. Extensions to Ada 83 25.a The rules for full conformance are relaxed - they are now based on the structure of constructs, rather than the sequence of lexical elements. This implies, for example, that "(X, Y: T)" conforms fully with "(X: T; Y: T)", and "(X: T)" conforms fully with "(X: in T)". Wording Changes from Ada 95 25.b/2 {8652/0011} {AI95-00117-01} Corrigendum: Clarified that the default convention is Ada. Also clarified that the convention of a primitive operation of a tagged type is the same as that of the type. 25.c/2 {8652/0018} {AI95-00175-01} Corrigendum: Added wording to ensure that two attributes conform only if they have the same attribute_designator. 25.d/2 {AI95-00252-01} {AI95-00254-01} {AI95-00407-01} Defined the calling convention for anonymous access-to-subprogram types and for prefixed views of subprograms (see 4.1.3). 25.e/2 {AI95-00318-02} Defined the conformance of access result types (see 6.1). 25.f/2 {AI95-00345-01} {AI95-00397-01} Defined the prefixed view profile of subprograms for later use. 25.g/2 {AI95-00409-01} Defined the conformance of anonymous access-to-subprogram parameters. Incompatibilities With Ada 2005 25.h/3 {AI05-0046-1} Correction: Now require null_exclusions to match for full conformance. While this is technically incompatible with Ada 2005 as defined by Amendment 1, it is a new Ada 2005 feature and it is unlikely that users have been intentionally taking advantage of the ability to write mismatching exclusions. In any case, it is easy to fix: add a null_exclusion where needed for conformance. 25.i/3 {AI05-0134-1} Correction: Now require full conformance of anonymous access-to-subprogram parameters and results for full conformance. This is necessary so that there is no confusion about the default expression that is used for a call. While this is technically incompatible with Ada 2005 as defined by Amendment 1, it is a new Ada 2005 feature and it is unlikely that users have been intentionally taking advantage and writing different default expressions. In any case, it is easy to fix: change any default expressions that don't conform so that they do conform. 25.j/3 {AI05-0207-1} Correction: Now include the presence or absence of constant in access parameters to be considered when checking mode conformance. This is necessary to prevent modification of constants. While this is technically incompatible with Ada 2005 as defined by Amendment 1, it is a new Ada 2005 feature and it is unlikely that users have been intentionally taking advantage and writing mismatching access types. Wording Changes from Ada 2005 25.k/3 {AI05-0142-4} Explicitly aliased parameters are included as part of mode conformance (since it affects the parameter passing mechanism). Extensions to Ada 2012 25.l/4 {AI05-0107-1} {AI05-0159-1} Corrigendum: We now define that a prefixed view of a subprogram with synchronization kind By_Protected_Procedure can be used as the prefix of 'Access for an access-to-protected type. We consider this a correction as it certainly appears that it ought to work, but in original Ada 2012 it would have had a convention mismatch. Wording Changes from Ada 2012 25.m/4 {AI05-0050-1} Corrigendum: We now define how two expressions containing quantified expressions can fully conform. This isn't incompatible, as the original Ada 2012 never allowed such expressions to conform (the declarations in each formally being different). Neither is it an extension as one would expect these to conform. 6.3.2 Inline Expansion of Subprograms 1 [Subprograms may be expanded in line at the call site.] Paragraphs 2 through 4 were moved to Annex J, "Obsolescent Features". Static Semantics 5/3 {AI05-0229-1} For a callable entity or a generic subprogram, the following language-defined representation aspect may be specified: 5.1/3 Inline The type of aspect Inline is Boolean. When aspect Inline is True for a callable entity, inline expansion is desired for all calls to that entity. When aspect Inline is True for a generic subprogram, inline expansion is desired for all calls to all instances of that generic subprogram. 5.2/3 If directly specified, the aspect_definition shall be a static expression. [This aspect is never inherited;] if not directly specified, the aspect is False. 5.a/3 Aspect Description for Inline: For efficiency, Inline calls are requested for a subprogram. 5.b/3 This paragraph was deleted.{AI05-0229-1} 5.c/3 This paragraph was deleted. 5.d/3 This paragraph was deleted. 5.e/3 Ramification: {AI05-0229-1} The meaning of a subprogram can be changed by inline expansion as requested by aspect Inline only in the presence of failing checks (see 11.6). Implementation Permissions 6/3 {AI05-0229-1} For each call, an implementation is free to follow or to ignore the recommendation determined by the Inline aspect. 6.a Ramification: Note, in particular, that the recommendation cannot always be followed for a recursive call, and is often infeasible for entries. Note also that the implementation can inline calls even when no such desire was expressed via the Inline aspect, so long as the semantics of the program remains unchanged. Incompatibilities With Ada 83 7.a/3 This paragraph was deleted.{AI95-00309-01} {AI05-0229-1} Extensions to Ada 83 7.b/3 This paragraph was deleted.{AI05-0229-1} Extensions to Ada 95 7.c/3 This paragraph was deleted.{AI95-00309-01} {AI05-0229-1} Extensions to Ada 2005 7.d/3 {AI05-0229-1} Aspect Inline is new; pragma Inline is now obsolescent. 6.4 Subprogram Calls 1 A subprogram call is either a procedure_call_statement or a function_call; [it invokes the execution of the subprogram_body. The call specifies the association of the actual parameters, if any, with formal parameters of the subprogram.] Syntax 2 procedure_call_statement ::= procedure_name; | procedure_prefix actual_parameter_part; 3 function_call ::= function_name | function_prefix actual_parameter_part 3.a/3 To be honest: {AI05-0005-1} For the purpose of non-syntax rules, infix operator calls are considered function_calls. See 6.6. 4 actual_parameter_part ::= (parameter_association {, parameter_association}) 5 parameter_association ::= [formal_parameter_selector_name =>] explicit_actual_parameter 6 explicit_actual_parameter ::= expression | variable_name 7 A parameter_association is named or positional according to whether or not the formal_parameter_selector_name is specified. Any positional associations shall precede any named associations. Named associations are not allowed if the prefix in a subprogram call is an attribute_- reference. 7.a Ramification: This means that the formal parameter names used in describing predefined attributes are to aid presentation of their semantics, but are not intended for use in actual calls. Name Resolution Rules 8/2 {AI95-00310-01} The name or prefix given in a procedure_call_statement shall resolve to denote a callable entity that is a procedure, or an entry renamed as (viewed as) a procedure. The name or prefix given in a function_call shall resolve to denote a callable entity that is a function. The name or prefix shall not resolve to denote an abstract subprogram unless it is also a dispatching subprogram. [When there is an actual_parameter_- part, the prefix can be an implicit_dereference of an access-to-subprogram value.] 8.a.1/2 Discussion: {AI95-00310-01} This rule is talking about dispatching operations (which is a static concept) and not about dispatching calls (which is a dynamic concept). 8.a Ramification: The function can be an operator, enumeration literal, attribute that is a function, etc. 9 A subprogram call shall contain at most one association for each formal parameter. Each formal parameter without an association shall have a default_expression (in the profile of the view denoted by the name or prefix ). [This rule is an overloading rule (see 8.6).] 9.a/3 Proof: {AI05-0240-1} All Name Resolution Rules are overloading rules, see 8.6. Dynamic Semantics 10/2 {AI95-00345-01} For the execution of a subprogram call, the name or prefix of the call is evaluated, and each parameter_association is evaluated (see 6.4.1). If a default_expression is used, an implicit parameter_association is assumed for this rule. These evaluations are done in an arbitrary order. The subprogram_body is then executed, or a call on an entry or protected subprogram is performed (see 3.9.2). Finally, if the subprogram completes normally, then after it is left, any necessary assigning back of formal to actual parameters occurs (see 6.4.1). 10.a Discussion: The implicit association for a default is only for this run-time rule. At compile time, the visibility rules are applied to the default at the place where it occurs, not at the place of a call. 10.b To be honest: If the subprogram is inherited, see 3.4, " Derived Types and Classes". 10.c If the subprogram is protected, see 9.5.1, " Protected Subprograms and Protected Actions". 10.d If the subprogram is really a renaming of an entry, see 9.5.3, "Entry Calls". 10.d.1/2 {AI95-00345-01} If the subprogram is implemented by an entry or protected subprogram, it will be treated as a dispatching call to the corresponding entry (see 9.5.3, "Entry Calls") or protected subprogram (see 9.5.1, " Protected Subprograms and Protected Actions"). 10.e/2 {AI95-00348-01} Normally, the subprogram_body that is executed by the above rule is the one for the subprogram being called. For an enumeration literal, implicitly declared (but noninherited) subprogram, null procedure, or an attribute that is a subprogram, an implicit body is assumed. For a dispatching call, 3.9.2, " Dispatching Operations of Tagged Types" defines which subprogram_body is executed. 10.1/2 {AI95-00407-01} If the name or prefix of a subprogram call denotes a prefixed view (see 4.1.3), the subprogram call is equivalent to a call on the underlying subprogram, with the first actual parameter being provided by the prefix of the prefixed view (or the Access attribute of this prefix if the first formal parameter is an access parameter), and the remaining actual parameters given by the actual_parameter_part, if any. 11/2 {AI95-00318-02} The exception Program_Error is raised at the point of a function_call if the function completes normally without executing a return statement. 11.a Discussion: We are committing to raising the exception at the point of call, for uniformity - see AI83-00152. This happens after the function is left, of course. 11.b Note that there is no name for suppressing this check, since the check imposes no time overhead and minimal space overhead (since it can usually be statically eliminated as dead code). 12/2 {AI95-00231-01} A function_call denotes a constant, as defined in 6.5; the nominal subtype of the constant is given by the nominal subtype of the function result. Examples 13 Examples of procedure calls: 14 Traverse_Tree; -- see 6.1 Print_Header(128, Title, True); -- see 6.1 15 Switch(From => X, To => Next); -- see 6.1 Print_Header(128, Header => Title, Center => True); -- see 6.1 Print_Header(Header => Title, Center => True, Pages => 128); -- see 6.1 16 Examples of function calls: 17 Dot_Product(U, V) -- see 6.1 and 6.3 Clock -- see 9.6 F.all -- presuming F is of an access-to-subprogram type - see 3.10 18 Examples of procedures with default expressions: 19 procedure Activate(Process : in Process_Name; After : in Process_Name := No_Process; Wait : in Duration := 0.0; Prior : in Boolean := False); 20/3 {AI05-0299-1} procedure Pair(Left, Right : in Person_Name := new Person(M)); -- see 3.10.1 21 Examples of their calls: 22 Activate(X); Activate(X, After => Y); Activate(X, Wait => 60.0, Prior => True); Activate(X, Y, 10.0, False); 23/3 {AI05-0299-1} Pair; Pair(Left => new Person(F), Right => new Person(M)); NOTES 24 9 If a default_expression is used for two or more parameters in a multiple parameter_specification, the default_expression is evaluated once for each omitted parameter. Hence in the above examples, the two calls of Pair are equivalent. Examples 25 Examples of overloaded subprograms: 26 procedure Put(X : in Integer); procedure Put(X : in String); 27 procedure Set(Tint : in Color); procedure Set(Signal : in Light); 28 Examples of their calls: 29 Put(28); Put("no possible ambiguity here"); 30 Set(Tint => Red); Set(Signal => Red); Set(Color'(Red)); 31 -- Set(Red) would be ambiguous since Red may -- denote a value either of type Color or of type Light Wording Changes from Ada 83 31.a We have gotten rid of parameters "of the form of a type conversion" (see RM83-6.4.1(3)). The new view semantics of type_conversions allows us to use normal type_conversions instead. 31.b We have moved wording about run-time semantics of parameter associations to 6.4.1. 31.c We have moved wording about raising Program_Error for a function that falls off the end to here from RM83-6.5. Extensions to Ada 95 31.d/2 {AI95-00310-01} Nondispatching abstract operations are no longer considered when resolving a subprogram call. That makes it possible to use abstract to "undefine" a predefined operation for an untagged type. That's especially helpful when defining custom arithmetic packages. Wording Changes from Ada 95 31.e/2 {AI95-00231-01} Changed the definition of the nominal subtype of a function_call to use the nominal subtype wording of 6.1, to take into account null_exclusions and access result types. 31.f/2 {AI95-00345-01} Added wording to clarify that the meaning of a call on a subprogram "implemented by" an entry or protected operation is defined by 3.9.2. 31.g/2 {AI95-00407-01} Defined the meaning of a call on a prefixed view of a subprogram (see 4.1.3). 6.4.1 Parameter Associations 1 [ A parameter association defines the association between an actual parameter and a formal parameter.] Language Design Principles 1.a The parameter passing rules for out parameters are designed to ensure that the parts of a type that have implicit initial values (see 3.3.1) don't become "de-initialized" by being passed as an out parameter. 1.b/3 {AI05-0142-4} For explicitly aliased parameters of functions, we will ensure at the call site that a part of the parameter can be returned as part of the function result without creating a dangling pointer. We do this with accessibility checks at the call site that all actual objects of explicitly aliased parameters live at least as long as the function result; then we can allow them to be returned as access discriminants or anonymous access results, as those have the master of the function result. Name Resolution Rules 2/3 {AI05-0118-1} The formal_parameter_selector_name of a named parameter_- association shall resolve to denote a parameter_specification of the view being called; this is the formal parameter of the association. The formal parameter for a positional parameter_association is the parameter with the corresponding position in the formal part of the view being called. 2.a/3 To be honest: {AI05-0118-1} For positional parameters, the " corresponding position" is calculated after any transformation of prefixed views. 3 The actual parameter is either the explicit_actual_parameter given in a parameter_association for a given formal parameter, or the corresponding default_expression if no parameter_association is given for the formal parameter. The expected type for an actual parameter is the type of the corresponding formal parameter. 3.a To be honest: The corresponding default_expression is the one of the corresponding formal parameter in the profile of the view denoted by the name or prefix of the call. 4 If the mode is in, the actual is interpreted as an expression; otherwise, the actual is interpreted only as a name, if possible. 4.a/4 Ramification: {AI12-0005-1} This formally resolves the ambiguity present in the syntax rule for explicit_actual_parameter. This matters as an expression that is a name is evaluated and represents a value while a name by itself can be an object; if the mode is not in, we want the parameter to interpreted as an object. Note that we don't actually require that the actual be a name if the mode is not in; we do that below. 4.b/4 {AI12-0005-1} This wording uses "interpreted as" rather than "shall be" so that this rule is not used to resolve overloading; it is solely about evaluation as described above. We definitely do not want to allow oddities like the presence of parentheses requiring the selection of an in formal parameter as opposed to an otherwise matching in out parameter. Legality Rules 5 If the mode is in out or out, the actual shall be a name that denotes a variable. 5.a Discussion: We no longer need "or a type_conversion whose argument is the name of a variable," because a type_conversion is now a name, and a type_conversion of a variable is a variable. 5.b Reason: The requirement that the actual be a (variable) name is not an overload resolution rule, since we don't want the difference between expression and name to be used to resolve overloading. For example: 5.c procedure Print(X : in Integer; Y : in Boolean := True); procedure Print(Z : in out Integer); . . . Print(3); -- Ambiguous! 5.d The above call to Print is ambiguous even though the call is not compatible with the second Print which requires an actual that is a (variable) name ("3" is an expression, not a name). This requirement is a legality rule, so overload resolution fails before it is considered, meaning that the call is ambiguous. 5.1/4 {AI12-0074-1} {AI12-0159-1} If the mode is out, the actual parameter is a view conversion, and the type of the formal parameter is an access type or a scalar type that has the Default_Value aspect specified, then 5.2/4 * there shall exist a type (other than a root numeric type) that is an ancestor of both the target type and the operand type; and 5.3/4 * in the case of a scalar type, the type of the operand of the conversion shall have the Default_Value aspect specified. 5.4/4 {AI12-0074-1} {AI12-0159-1} In addition to the places where Legality Rules normally apply (see 12.3), these rules also apply in the private part of an instance of a generic unit. 5.e/4 Reason: These rules are needed in order to ensure that a well-defined parameter value is passed. 6/3 {AI05-0102-1} {AI05-0142-4} If the formal parameter is an explicitly aliased parameter, the type of the actual parameter shall be tagged or the actual parameter shall be an aliased view of an object. Further, if the formal parameter subtype F is untagged: 6.1/3 * the subtype F shall statically match the nominal subtype of the actual object; or 6.2/3 * the subtype F shall be unconstrained, discriminated in its full view, and unconstrained in any partial view. 6.a/3 Ramification: Tagged objects (and tagged aggregates for in parameters) do not need to be aliased. This matches the behavior of unaliased formal parameters of tagged types, which allow 'Access to be taken of the formal parameter regardless of the form of the actual parameter. 6.b/3 Reason: We need the subtype check on untagged actual parameters so that the requirements of 'Access are not lost. 'Access makes its checks against the nominal subtype of its prefix, and parameter passing can change that subtype. But we don't want this parameter passing to change the objects that would be allowed as the prefix of 'Access. This is particularly important for arrays, where we don't want to require any additional implementation burden. 6.b.1/4 Discussion: {AI12-0095-1} We assume the worst in a generic body whether or not a formal subtype has a constrained partial view; specifically, in a generic body a discriminated subtype is considered to have a constrained partial view if it is a descendant of an untagged generic formal private or derived type (see 12.5.1 for the formal definition of this rule). 6.3/4 {AI12-0095-1} In addition to the places where Legality Rules normally apply (see 12.3), these rules also apply in the private part of an instance of a generic unit. 6.4/3 {AI05-0142-4} {AI05-0234-1} In a function call, the accessibility level of the actual object for each explicitly aliased parameter shall not be statically deeper than the accessibility level of the master of the call (see 3.10.2). 6.c/3 Discussion: Since explicitly aliased parameters are either tagged or required to be objects, there is always an object (possibly anonymous) to talk about. This is discussing the static accessibility level of the actual object; it does not depend on any runtime information (for instance when the actual object is a formal parameter of another subprogram, it does not depend on the actual parameter of that other subprogram). 6.d/4 Ramification: {AI12-0095-1} This accessibility check (and its dynamic cousin as well) can only fail if the master of the function call (which is defined in the Heart of Darkness, or 3.10.2 if you prefer) is different than the master directly enclosing the call. The most likely place where this will occur is in the initializer of an allocator; in almost all other cases this check will always pass. 6.5/3 {AI05-0144-2} Two names are known to denote the same object if: 6.6/3 * both names statically denote the same stand-alone object or parameter; or 6.7/3 * both names are selected_components, their prefixes are known to denote the same object, and their selector_names denote the same component; or 6.8/3 * both names are dereferences (implicit or explicit) and the dereferenced names are known to denote the same object; or 6.9/3 * both names are indexed_components, their prefixes are known to denote the same object, and each of the pairs of corresponding index values are either both static expressions with the same static value or both names that are known to denote the same object; or 6.10/3 * both names are slices, their prefixes are known to denote the same object, and the two slices have statically matching index constraints; or 6.11/3 * one of the two names statically denotes a renaming declaration whose renamed object_name is known to denote the same object as the other, the prefix of any dereference within the renamed object_name is not a variable, and any expression within the renamed object_name contains no references to variables nor calls on nonstatic functions. 6.e/3 Reason: This exposes known renamings of slices, indexing, and so on to this definition. In particular, if we have 6.f/3 C : Character renames S(1); 6.g/3 then C and S(1) are known to denote the same object. 6.h/3 We need the requirement that no variables occur in the prefixes of dereferences and in (index) expressions of the renamed object in order to avoid problems from later changes to those parts of renamed names. Consider: 6.i/3 type Ref is access Some_Type; Ptr : Ref := new Some_Type'(...); X : Some_Type renames Ptr.all; begin Ptr := new Some_Type'(...); P (Func_With_Out_Params (Ptr.all), X); 6.j/3 X and Ptr.all should not be known to denote the same object, since they denote different allocated objects (and this is not an unreasonable thing to do). 6.k/3 To be honest: The exclusion of variables from renamed object_names is not enough to prevent altering the value of the name or expression by another access path. For instance, both in parameters passed by reference and access-to-constant values can designate variables. For the intended use of "known to be the same object", this is OK; the modification via another access path is very tricky and it is OK to reject code that would be buggy except for the tricky code. Assuming Element is an elementary type, consider the following example: 6.l/3 Global : Tagged_Type; 6.m/3 procedure Foo (Param : in Tagged_Type := Global) is X : Element renames Some_Global_Array (Param.C); begin Global.C := Global.C + 1; Swap (X, Some_Global_Array (Param.C)); 6.n/3 The rules will flag the call of procedure Swap as illegal, since X and Some_Global_Array (Parameter.C) are known to denote the same object (even though they will actually represent different objects if Param = Global). But this is only incorrect if the parameter actually is Global and not some other value; the error could exist for some calls. So this flagging seems harmless. 6.o/3 Similar examples can be constructed using stand-alone composite constants with controlled or immutably limited components, and (as previously noted) with dereferences of access-to-constant values. Even when these examples flag a call incorrectly, that call depends on very tricky code (modifying the value of a constant); the code is likely to confuse future maintainers as well and thus we do not mind rejecting it. 6.p/3 Discussion: Whether or not names or prefixes are known to denote the same object is determined statically. If the name contains some dynamic portion other than a dereference, indexed_component, or slice, it is not "known to denote the same object". 6.q/3 These rules make no attempt to handle slices of objects that are known to be the same when the slices have dynamic bounds (other than the trivial case of bounds being defined by the same subtype), even when the bounds could be proven to be the same, as it is just too complex to get right and these rules are intended to be conservative. 6.r/3 Ramification: "Known to denote the same object" is intended to be an equivalence relationship, that is, it is reflexive, symmetric, and transitive. We believe this follows from the rules. For instance, given the following declarations: 6.s/3 S : String(1..10); ONE : constant Natural := 1; R : Character renames S(1); 6.t/3 the names R and S(1) are known to denote the same object by the sixth bullet, and S(1) and S(ONE) are known to denote the same object by the fourth bullet, so using the sixth bullet on R and S(ONE), we simply have to test S(1) vs. S(ONE), which we already know denote the same object. 6.12/3 {AI05-0144-2} Two names are known to refer to the same object if 6.13/3 * The two names are known to denote the same object; or 6.14/3 * One of the names is a selected_component, indexed_component, or slice and its prefix is known to refer to the same object as the other name; or 6.15/3 * One of the two names statically denotes a renaming declaration whose renamed object_name is known to refer to the same object as the other name. 6.u/3 Reason: This ensures that names Prefix.Comp and Prefix are known to refer to the same object for the purposes of the rules below. This intentionally does not include dereferences; we only want to worry about accesses to the same object, and a dereference changes the object in question. (There is nothing shared between an access value and the object it designates.) 6.16/3 {AI05-0144-2} If a call C has two or more parameters of mode in out or out that are of an elementary type, then the call is legal only if: 6.17/3 * For each name N that is passed as a parameter of mode in out or out to the call C, there is no other name among the other parameters of mode in out or out to C that is known to denote the same object. 6.v/3 To be honest: This means visibly an elementary type; it does not include partial views of elementary types (partial views are always composite). That's necessary to avoid having Legality Rules depend on the contents of the private part. 6.18/3 {AI05-0144-2} If a construct C has two or more direct constituents that are names or expressions whose evaluation may occur in an arbitrary order, at least one of which contains a function call with an in out or out parameter, then the construct is legal only if: 6.w/3 Ramification: All of the places where the language allows an arbitrary order can be found by looking in the index under "arbitrary order, allowed". Note that this listing includes places that don't involve names or expressions (such as checks or finalization). 6.19/3 * For each name N that is passed as a parameter of mode in out or out to some inner function call C2 (not including the construct C itself), there is no other name anywhere within a direct constituent of the construct C other than the one containing C2, that is known to refer to the same object. 6.x/3 Ramification: This requirement cannot fail for a procedure or entry call alone; there must be at least one function with an in out or out parameter called as part of a parameter expression of the call in order for it to fail. 6.y/3 Reason: These rules prevent obvious cases of dependence on the order of evaluation of names or expressions. Such dependence is usually a bug, and in any case, is not portable to another implementation (or even another optimization setting). 6.z/3 In the case that the top-level construct C is a call, these rules do not require checks for most in out parameters, as the rules about evaluation of calls prevent problems. Similarly, we do not need checks for short circuit operations or other operations with a defined order of evaluation. The rules about arbitrary order (see 1.1.4) allow evaluating parameters and writing parameters back in an arbitrary order, but not interleaving of evaluating parameters of one call with writing parameters back from another - that would not correspond to any allowed sequential order. 6.20/3 {AI05-0144-2} For the purposes of checking this rule: 6.21/3 * For an array aggregate, an expression associated with a discrete_choice_list that has two or more discrete choices, or that has a nonstatic range, is considered as two or more separate occurrences of the expression; 6.22/3 * For a record aggregate: 6.23/3 * The expression of a record_component_association is considered to occur once for each associated component; and 6.24/3 * The default_expression for each record_component_association with <> for which the associated component has a default_expression is considered part of the aggregate; 6.25/3 * For a call, any default_expression evaluated as part of the call is considered part of the call. 6.aa/3 Ramification: We do not check expressions that are evaluated only because of a component initialized by default in an aggregate (via <>). Dynamic Semantics 7 For the evaluation of a parameter_association: 8 * The actual parameter is first evaluated. 9 * For an access parameter, the access_definition is elaborated, which creates the anonymous access type. 10 * For a parameter [(of any mode)] that is passed by reference (see 6.2 ), a view conversion of the actual parameter to the nominal subtype of the formal parameter is evaluated, and the formal parameter denotes that conversion. 10.a Discussion: We are always allowing sliding, even for [in] out by-reference parameters. 11 * For an in or in out parameter that is passed by copy (see 6.2), the formal parameter object is created, and the value of the actual parameter is converted to the nominal subtype of the formal parameter and assigned to the formal. 11.a Ramification: The conversion mentioned here is a value conversion. 12 * For an out parameter that is passed by copy, the formal parameter object is created, and: 13/3 * {AI05-0153-3} {AI05-0196-1} For an access type, the formal parameter is initialized from the value of the actual, without checking that the value satisfies any constraint, any predicate, or any exclusion of the null value; 13.a Reason: This preserves the Language Design Principle that an object of an access type is always initialized with a " reasonable" value. 13.1/4 * {AI05-0153-3} {AI05-0228-1} {AI12-0074-1} {AI12-0159-1} For a scalar type that has the Default_Value aspect specified, the formal parameter is initialized from the value of the actual, without checking that the value satisfies any constraint or any predicate. Furthermore, if the actual parameter is a view conversion and either 13.2/4 * {AI12-0074-1} there exists no type (other than a root numeric type) that is an ancestor of both the target type and the type of the operand of the conversion; or 13.3/4 * {AI12-0074-1} the Default_Value aspect is unspecified for the type of the operand of the conversion 13.4/4 {AI12-0074-1} then Program_Error is raised; 13.b/3 Reason: This preserves the Language Design Principle that all objects of a type with an implicit initial value are initialized. This is important so that a programmer can guarantee that all objects of a scalar type have a valid value with a carefully chosen Default_Value. 13.c/3 Implementation Note: This rule means that out parameters of a subtype T with a specified Default_Value need to be large enough to support any possible value of the base type of T. In contrast, a type that does not have a Default_Value only need support the size of the subtype (since no values are passed in). 13.d/4 Discussion: The Program_Error case can only occur in the body of an instance of a generic unit. Legality Rules will catch all other cases. Implementations that macro-expand generics can always detect this case when the enclosing instance body is expanded. 14 * For a composite type with discriminants or that has implicit initial values for any subcomponents (see 3.3.1), the behavior is as for an in out parameter passed by copy. 14.a Reason: This ensures that no part of an object of such a type can become "de-initialized" by being part of an out parameter. 14.b Ramification: This includes an array type whose component type is an access type, and a record type with a component that has a default_expression, among other things. 15 * For any other type, the formal parameter is uninitialized. If composite, a view conversion of the actual parameter to the nominal subtype of the formal is evaluated [(which might raise Constraint_Error)], and the actual subtype of the formal is that of the view conversion. If elementary, the actual subtype of the formal is given by its nominal subtype. 15.a/3 Ramification: {AI05-0228-1} This case covers scalar types that do not have Default_Value specified, and composite types whose subcomponent's subtypes do not have any implicit initial values. The view conversion for composite types ensures that if the lengths don't match between an actual and a formal array parameter, the Constraint_Error is raised before the call, rather than after. 15.1/3 * {AI05-0142-4} {AI05-0234-1} In a function call, for each explicitly aliased parameter, a check is made that the accessibility level of the master of the actual object is not deeper than that of the master of the call (see 3.10.2). 15.a.1/3 Ramification: If the actual object to a call C is a formal parameter of some function call F, no dynamic check against the master of the actual parameter of F is necessary. Any case which could fail the dynamic check is already statically illegal (either at the call site of F, or at the call site C). This is important, as it would require nasty distributed overhead to accurately know the dynamic accessibility of a formal parameter (all tagged and explicitly aliased parameters would have to carry accessibility levels). 16 A formal parameter of mode in out or out with discriminants is constrained if either its nominal subtype or the actual parameter is constrained. 17 After normal completion and leaving of a subprogram, for each in out or out parameter that is passed by copy, the value of the formal parameter is converted to the subtype of the variable given as the actual parameter and assigned to it. These conversions and assignments occur in an arbitrary order. 17.a Ramification: The conversions mentioned above during parameter passing might raise Constraint_Error - (see 4.6). 17.b Ramification: If any conversion or assignment as part of parameter passing propagates an exception, the exception is raised at the place of the subprogram call; that is, it cannot be handled inside the subprogram_body. 17.c Proof: Since these checks happen before or after executing the subprogram_body, the execution of the subprogram_body does not dynamically enclose them, so it can't handle the exceptions. 17.d Discussion: The variable we're talking about is the one denoted by the variable_name given as the explicit_actual_parameter. If this variable_name is a type_conversion, then the rules in 4.6 for assigning to a view conversion apply. That is, if X is of subtype S1, and the actual is S2(X), the above-mentioned conversion will convert to S2, and the one mentioned in 4.6 will convert to S1. Erroneous Execution 18/3 {AI05-0008-1} If the nominal subtype of a formal parameter with discriminants is constrained or indefinite, and the parameter is passed by reference, then the execution of the call is erroneous if the value of any discriminant of the actual is changed while the formal parameter exists (that is, before leaving the corresponding callable construct). Extensions to Ada 83 18.a In Ada 95, a program can rely on the fact that passing an object as an out parameter does not "de-initialize" any parts of the object whose subtypes have implicit initial values. (This generalizes the RM83 rule that required copy-in for parts that were discriminants or of an access type.) Wording Changes from Ada 83 18.b/3 {AI05-0299-1} We have eliminated the subclause on Default Parameters, as it is subsumed by earlier subclauses. Inconsistencies With Ada 2005 18.c/3 {AI05-0196-1} Correction: Clarified that out parameters of an access type are not checked for null exclusions when they are passed in (which is similar to the behavior for constraints). This was unspecified in Ada 2005, so a program which depends on the behavior of an implementation which does check the exclusion may malfunction. But a program depending on an exception being raised is unlikely. Incompatibilities With Ada 2005 18.d/3 {AI05-0144-2} Additional rules have been added to make illegal passing the same elementary object to more than one in out or out parameters of the same call. In this case, the result in the object could depend on the compiler version, optimization settings, and potentially the phase of the moon, so this check will mostly reject programs that are nonportable and could fail with any change. Even when the result is expected to be the same in both parameters, the code is unnecessarily tricky. Programs which fail this new check should be rare and are easily fixed by adding a temporary object. Wording Changes from Ada 2005 18.e/3 {AI05-0008-1} Correction: A missing rule was added to cover cases that were missed in Ada 95 and Ada 2005; specifically, that an in parameter passed by reference might have its discriminants changed via another path. Such cases are erroneous as requiring compilers to detect such errors would be expensive, and requiring such cases to work would be a major change of the user model (in parameters with discriminants could no longer be assumed constant). This is not an inconsistency, as compilers are not required to change any current behavior. 18.f/3 {AI05-0102-1} Correction: Moved implicit conversion Legality Rule to 8.6. 18.g/3 {AI05-0118-1} Correction: Added a definition for positional parameters, as this is missing from Ada 95 and later. 18.h/3 {AI05-0142-4} Rules have been added defining the legality and dynamic checks needed for explicitly aliased parameters (see 6.1). 18.i/3 {AI05-0144-2} Additional rules have been added such that passing an object to an in out or out parameter of a function is illegal if it is used elsewhere in a construct which allows evaluation in an arbitrary order. Such calls are not portable (since the results may depend on the evaluation order), and the results could even vary because of optimization settings and the like. Thus they've been banned. Incompatibilities With Ada 2012 18.j/4 {AI12-0074-1} {AI12-0159-1} Corrigendum: Added rules to ensure that the value passed into a out parameter for elementary types is well-defined in the case of a view conversion. The new rules can be incompatible. For a view conversion to an unrelated type with the Default_Value aspect specified, the aspect is new in Ada 2012 so it should be unlikely to occur in existing code. For a view conversion to an unrelated access type, the incompatibility is possible as this could be written in Ada 95, but such a view conversion is thought to be rare. In both cases, declaring and passing a temporary rather than a view conversion will eliminate the problem. 18.k/4 {AI12-0095-1} Corrigendum: Because of a rule added in 12.5.1, the checks for the passing of an object to an explicitly aliased parameter in a generic body were strengthened to use an assume the worst rule. This case is rather unlikely as a formal private or derived type with discriminants is required along with an explicitly aliased parameter whose type doesn't statically match the formal type. Such a program is very unlikely, especially as explicitly aliased parameters are a new Ada 2012 feature. 6.5 Return Statements 1/2 {AI95-00318-02} A simple_return_statement or extended_return_statement (collectively called a return statement) is used to complete the execution of the innermost enclosing subprogram_body, entry_body, or accept_statement. Syntax 2/2 {AI95-00318-02} simple_return_statement ::= return [expression]; 2.1/3 {AI05-0277-1} extended_return_object_declaration ::= defining_identifier : [aliased][constant] return_subtype_indication [:= expression] 2.2/3 {AI95-00318-02} {AI05-0015-1} {AI05-0053-1} {AI05-0277-1} {AI05-0299-1} extended_return_statement ::= return extended_return_object_declaration [do handled_sequence_of_statements end return]; 2.3/2 {AI95-00318-02} return_subtype_indication ::= subtype_indication | access_definition Name Resolution Rules 3/2 {AI95-00318-02} The result subtype of a function is the subtype denoted by the subtype_mark, or defined by the access_definition, after the reserved word return in the profile of the function. The expected type for the expression, if any, of a simple_return_statement is the result type of the corresponding function. The expected type for the expression of an extended_return_statement is that of the return_subtype_indication. 3.a To be honest: The same applies to generic functions. Legality Rules 4/2 {AI95-00318-02} A return statement shall be within a callable construct, and it applies to the innermost callable construct or extended_return_statement that contains it. A return statement shall not be within a body that is within the construct to which the return statement applies. 4.a/4 To be honest: {AI12-0089-1} The above also applies to generic subprograms, even though they are not callable constructs. (An instance of a generic subprogram is a callable construct, but not a generic subprogram itself.) 5/3 {AI95-00318-02} {AI05-0015-1} A function body shall contain at least one return statement that applies to the function body, unless the function contains code_statements. A simple_return_statement shall include an expression if and only if it applies to a function body. An extended_return_statement shall apply to a function body. An extended_return_statement with the reserved word constant shall include an expression. 5.a/4 Reason: {AI95-00318-02} {AI12-0022-1} The requirement that a function body has to have at least one return statement is a " helpful" restriction. There has been some interest in lifting this restriction, or allowing a raise statement to substitute for the return statement. However, there was enough interest in leaving it as is that we decided not to change it. Note that for Ada 2012, Corrigendum 1, a return statement whose expression is a raise_expression can be given in any function body (the raise_expression will match any type), so there is much less need to eliminate this rule. 5.b/2 Ramification: {AI95-00318-02} A return statement can apply to an extended_return_statement, so a simple_return_statement without an expression can be given in one. However, neither simple_return_- statement with an expression nor an extended_return_statement can be given inside an extended_return_statement, as they must apply (directly) to a function body. 5.b.1/4 {AI12-0089-1} Since a "function body" includes a generic function body, this rule and all of the following Legality Rules apply to generic function bodies as well as non-generic function bodies. This is true even though a generic function is not a function. 5.1/2 {AI95-00318-02} For an extended_return_statement that applies to a function body: 5.2/3 * {AI95-00318-02} {AI05-0032-1} {AI05-0103-1} If the result subtype of the function is defined by a subtype_mark, the return_subtype_indication shall be a subtype_indication. The type of the subtype_indication shall be covered by the result type of the function. The subtype defined by the subtype_indication shall be statically compatible with the result subtype of the function; if the result type of the function is elementary, the two subtypes shall statically match. If the result subtype of the function is indefinite, then the subtype defined by the subtype_indication shall be a definite subtype, or there shall be an expression. 5.3/2 * {AI95-00318-02} If the result subtype of the function is defined by an access_definition, the return_subtype_indication shall be an access_definition. The subtype defined by the access_definition shall statically match the result subtype of the function. [The accessibility level of this anonymous access subtype is that of the result subtype.] 5.b.2/4 Proof: {AI12-0070-1} The accessibility of such anonymous access types is defined in the Heart of Darkness (aka 3.10.2). 5.4/3 * {AI05-0032-1} If the result subtype of the function is class-wide, the accessibility level of the type of the subtype defined by the return_subtype_indication shall not be statically deeper than that of the master that elaborated the function body. 5.b.3/3 Reason: In this case, the return_subtype_indication could be a specific type initialized by default; in that case there is no expression to check. 5.5/3 {AI95-00318-02} {AI05-0032-1} For any return statement that applies to a function body: 5.6/3 * {AI95-00318-02} {AI05-0188-1} [If the result subtype of the function is limited, then the expression of the return statement (if any) shall meet the restrictions described in 7.5.] 5.c/3 This paragraph was deleted.{AI05-0188-1} 5.7/3 * {AI95-00416-01} {AI05-0032-1} {AI05-0051-1} If the result subtype of the function is class-wide, the accessibility level of the type of the expression (if any) of the return statement shall not be statically deeper than that of the master that elaborated the function body. 5.d/4 Discussion: {AI05-0032-1} {AI05-0051-1} {AI12-0005-1} If the result type is class-wide, then there must be an expression of the return statement unless this is an extended_return_statement whose return_subtype_indication is a specific type. We have a separate rule to cover that case. Note that if an extended_return_statement has an expression, then both this rule and the next one must be satisfied. 5.8/3 * {AI05-0051-1} If the subtype determined by the expression of the simple_return_statement or by the return_subtype_indication has one or more access discriminants, the accessibility level of the anonymous access type of each access discriminant shall not be statically deeper than that of the master that elaborated the function body. 5.d.1/3 Discussion: We use the type used by the return statement rather than from the function return type since we want to check whenever the return object has access discriminants, even if the function return type doesn't have any (mostly for a class-wide type). 5.9/3 {AI05-0277-1} If the keyword aliased is present in an extended_return_object_declaration, the type of the extended return object shall be immutably limited. Static Semantics 5.10/3 {AI95-00318-02} {AI05-0015-1} {AI05-0144-2} Within an extended_return_statement, the return object is declared with the given defining_identifier, with the nominal subtype defined by the return_subtype_- indication. An extended_return_statement with the reserved word constant is a full constant declaration that declares the return object to be a constant object. Dynamic Semantics 5.11/3 {AI95-00318-02} {AI95-00416-01} {AI05-0032-1} For the execution of an extended_return_statement, the subtype_indication or access_definition is elaborated. This creates the nominal subtype of the return object. If there is an expression, it is evaluated and converted to the nominal subtype (which might raise Constraint_Error - see 4.6); the return object is created and the converted value is assigned to the return object. Otherwise, the return object is created and initialized by default as for a stand-alone object of its nominal subtype (see 3.3.1). If the nominal subtype is indefinite, the return object is constrained by its initial value. A check is made that the value of the return object belongs to the function result subtype. Constraint_Error is raised if this check fails. 5.e/2 Ramification: If the result type is controlled or has a controlled part, appropriate calls on Initialize or Adjust are performed prior to executing the handled_sequence_of_statements, except when the initial expression is an aggregate (which requires build-in-place with no call on Adjust). 5.f/3 {AI05-0005-1} If the return statement is left without resulting in a return (for example, due to an exception propagated from the expression or the handled_sequence_of_statements, or a goto out of the handled_sequence_of_statements), if the return object has been created, it is finalized prior to leaving the return statement. If it has not been created when the return statement is left, it is not created or finalized. 5.g/3 {AI05-0032-1} Other rules ensure that the check required by this rule cannot fail unless the function has a class-wide result subtype where the associated specific subtype is constrained. In other cases, either the subtypes have to match or the function's subtype is unconstrained and needs no checking. 6/2 {AI95-00318-02} For the execution of a simple_return_statement, the expression (if any) is first evaluated, converted to the result subtype, and then is assigned to the anonymous return object. 6.a Ramification: The conversion might raise Constraint_Error - (see 4.6). 7/2 {AI95-00318-02} {AI95-00416-01} [If the return object has any parts that are tasks, the activation of those tasks does not occur until after the function returns (see 9.2).] 7.a/2 Proof: This is specified by the rules in 9.2. 7.b/2 Reason: Only the caller can know when task activations should take place, as it depends on the context of the call. If the function is being used to initialize the component of some larger object, then that entire object must be initialized before any task activations. Even after the outer object is fully initialized, task activations are still postponed until the begin at the end of the declarative part if the function is being used to initialize part of a declared object. 8/4 {AI95-00318-02} {AI95-00344-01} {AI05-0024-1} {AI05-0032-1} {AI12-0097-1} If the result type of a function is a specific tagged type, the tag of the return object is that of the result type. If the result type is class-wide, the tag of the return object is that of the value of the expression, unless the return object is defined by an extended_return_object_declaration with a subtype_indication that is specific, in which case it is that of the type of the subtype_indication. A check is made that the master of the type identified by the tag of the result includes the elaboration of the master that elaborated the function body. If this check fails, Program_Error is raised. 8.a/2 Ramification: {AI95-00318-02} The first sentence is true even if the tag of the expression is different, which could happen if the expression were a view conversion or a dereference of an access value. Note that for a limited type, because of the restriction to aggregates and function calls (and no conversions), the tag will already match. 8.b/2 Reason: {AI95-00318-02} The first rule ensures that a function whose result type is a specific tagged type always returns an object whose tag is that of the result type. This is important for dispatching on controlling result, and allows the caller to allocate the appropriate amount of space to hold the value being returned (assuming there are no discriminants). 8.c/3 The master check prevents the returned object from outliving its type. Note that this check cannot fail for a specific tagged type, as the tag represents the function's type, which necessarily must be declared outside of the function. 8.d/3 We can't use the normal accessibility level "deeper than" check here because we may have "incomparable" levels if the masters belong to two different tasks. This can happen when an accept statement calls a function declared in the enclosing task body, and the function returns an object passed to it from the accept statement, and this object was itself a parameter to the accept statement. 8.d.1/4 To be honest: {AI12-0097-1} The expression here is the return expression if the return statement is a simple_return_statement, and the initializing expression of the extended_return_object_declaration if the return statement is an extended_return_statement (ignoring any inner simple_return_statements, which necessarily cannot have an expression, and any other expressions inside of the extended_return_statement). 8.1/3 {AI05-0073-1} If the result subtype of the function is defined by an access_definition designating a specific tagged type T, a check is made that the result value is null or the tag of the object designated by the result value identifies T. Constraint_Error is raised if this check fails. 8.e/3 Reason: This check is needed so that dispatching on controlling access results works for tag-indeterminate functions. If it was not made, it would be possible for such functions to return an access to a descendant type, meaning the function could return an object with a tag different than the one assumed by the dispatching rules. Paragraphs 9 through 20 were deleted. 21/3 {AI95-00318-02} {AI95-00402-01} {AI95-00416-01} {AI05-0051-1} If any part of the specific type of the return object of a function (or coextension thereof) has one or more access discriminants whose value is not constrained by the result subtype of the function, a check is made that the accessibility level of the anonymous access type of each access discriminant, as determined by the expression or the return_subtype_indication of the return statement, is not deeper than the level of the master of the call (see 3.10.2). If this check fails, Program_Error is raised. 21.a/2 This paragraph was deleted. 21.b/2 Reason: The check prevents the returned object (for a nonlimited type) from outliving the object designated by one of its discriminants. The check is made on the values of the discriminants, which may come from the return_subtype_indication (if constrained), or the expression, but it is never necessary to check both. 21.c/3 Implementation Note: {AI05-0234-1} The reason for saying "any part of the specific type" is to simplify implementation. In the case of class-wide result objects, this allows the testing of a simple flag in the tagged type descriptor that indicates whether the specific type has any parts with access discriminants. By basing the test on the type of the object rather than the object itself, we avoid concerns about whether subcomponents in variant parts and of arrays (which might be empty) are present. 21.d/3 Discussion: {AI05-0234-1} For a function with a class-wide result type, the access values that need to be checked are determined by the tag of the return object. In order to implement this accessibility check in the case where the tag of the result is not known statically at the point of the return statement, an implementation may need to somehow associate with the tag of a specific tagged type an indication of whether the type has unconstrained access discriminants (explicit or inherited) or has any subcomponents with such discriminants. If an implementation is already maintaining a statically initialized descriptor of some kind for each specific tagged type, then an additional Boolean could be added to this descriptor. 21.e/3 {AI05-0005-1} {AI05-0234-1} Note that the flag should only be queried in the case where the result object might have access discriminants that might have subtypes with "bad" accessibility levels (as determined by the rules of 3.10.2 for determining the accessibility level of the type of an access discriminant in the expression or return_subtype_indication of a return statement). 21.f/3 Thus, in a case like 21.g/3 type Global is access T'Class; function F (Ptr : Global) return T'Class is begin return Ptr.all; end F; 21.h/3 there is no need for a run-time accessibility check. While an object of T'Class "might have" access discriminants, the accessibility of those potential discriminants cannot be bad. The setting of the bit doesn't matter and there is no need to query it. 21.i/3 On the other hand, given 21.j/3 function F return T'Class is Local : T'Class := ... ; begin return Local; end F; 21.k/3 In this case, a check would typically be required. 21.l/3 The need for including subcomponents in this check is illustrated by the following example: 21.m/3 X : aliased Integer; 21.n/3 type Component_Type (Discrim : access Integer := X'Access) is limited null record; 21.o/3 type Undiscriminated is record Fld : Component_Type; end record; 21.p/3 function F return Undiscriminated is Local : aliased Integer; begin return X : Undiscriminated := (Fld => (Discrim => Local'Access)) do Foo; end return; -- raises Program_Error after calling Foo. end F; 21.q/3 Ramification: {AI05-0234-1} In the case where the tag of the result is not known statically at the point of the return statement and the run-time accessibility check is needed, discriminant values and array bounds play no role in performing this check. That is, array components are assumed to have nonzero length and components declared within variant parts are assumed to be present. Thus, the check may be implemented simply by testing the aforementioned descriptor bit and conditionally raising Program_Error. 22/3 {AI95-00318-02} {AI05-0058-1} For the execution of an extended_return_- statement, the handled_sequence_of_statements is executed. Within this handled_- sequence_of_statements, the execution of a simple_return_statement that applies to the extended_return_statement causes a transfer of control that completes the extended_return_statement. Upon completion of a return statement that applies to a callable construct by the normal completion of a simple_- return_statement or by reaching the end return of an extended_return_statement, a transfer of control is performed which completes the execution of the callable construct, and returns to the caller. 22.a/3 Ramification: {AI05-0058-1} A transfer of control that completes an extended_return_statement (such as an exit or goto) does not cause a return to the caller unless it is caused by simple_return_statement (that is, triggers the second sentence of this paragraph). The return to the caller occurs for the simple_return_statement that applies to an extended_return_statement because the last sentence says "the normal completion of a simple_return_statement", which includes the one nested in the extended_return_statement. 23/2 {AI95-00318-02} In the case of a function, the function_call denotes a constant view of the return object. Implementation Permissions 24/3 {AI95-00416-01} {AI05-0050-1} For a function call used to initialize a composite object with a constrained nominal subtype or used to initialize a return object that is built in place into such an object: 24.1/3 * {AI05-0050-1} If the result subtype of the function is constrained, and conversion of an object of this subtype to the subtype of the object being initialized would raise Constraint_Error, then Constraint_Error may be raised before calling the function. 24.2/3 * {AI05-0050-1} If the result subtype of the function is unconstrained, and a return statement is executed such that the return object is known to be constrained, and conversion of the return object to the subtype of the object being initialized would raise Constraint_Error, then Constraint_Error may be raised at the point of the call (after abandoning the execution of the function body). 24.a/3 Reason: {AI95-00416-01} {AI05-0050-1} Without such a permission, it would be very difficult to implement "built-in-place" semantics. The intention is that the exception is raised at the same point that it would have been raised without the permission; it should not change handlers if the implementation switches between return-by-copy and built-in-place. This means that the exception is not handleable within the function, because in the return-by-copy case, the constraint check to verify that the result satisfies the constraints of the object being initialized happens after the function returns. This implies further that upon detecting such a situation, the implementation may need to simulate a goto to a point outside any local exception handlers prior to raising the exception. 24.b/3 Ramification: {AI95-00416-01} {AI05-0050-1} These permissions do not apply in the case of an extended return object with mutable discriminants. That's necessary because in that case a return object can be created with the "wrong" discriminants and then changed to the "right" discriminants later (but before returning). We don't want this case raising an exception when the canonical semantics will not do so. 24.c/3 {AI05-0050-1} It's still possible to write a program that will raise an exception using this permission that would not in the canonical semantics. That could happen if a return statement with the "wrong" discriminants or bounds is abandoned (via an exception, or for an extended_return_statement, via an exit or goto statement), and then a return statement with the "right" discriminants or bounds is executed. The only solution for this problem is to not have the permission at all, but this is too unusual of a case to worry about the effects of the permission, especially given the implementation difficulties for built-in-place objects that this permission is intended to ease. 24.d/3 {AI05-0050-1} Note that the mutable-discriminant case only happens when built-in-place initialization is optional. This means that any difficulties associated with implementing built-in-place initialization without these permissions can be sidestepped by not building in place. Examples 25 Examples of return statements: 26/2 {AI95-00318-02} return; -- in a procedure body, entry_body, -- accept_statement , or extended_return_statement 27 return Key_Value(Last_Index); -- in a function body 28/2 {AI95-00318-02} return Node : Cell do -- in a function body, see 3.10.1 for Cell Node.Value := Result; Node.Succ := Next_Node; end return; Incompatibilities With Ada 83 28.a/2 {AI95-00318-02} In Ada 95, if the result type of a function has a part that is a task, then an attempt to return a local variable will raise Program_Error. This is illegal in Ada 2005, see below. In Ada 83, if a function returns a local variable containing a task, execution is erroneous according to AI83-00867. However, there are other situations where functions that return tasks (or that return a variant record only one of whose variants includes a task) are correct in Ada 83 but will raise Program_Error according to the new rules. 28.b The rule change was made because there will be more types (protected types, limited controlled types) in Ada 95 for which it will be meaningless to return a local variable, and making all of these erroneous is unacceptable. The current rule was felt to be the simplest that kept upward incompatibilities to situations involving returning tasks, which are quite rare. Wording Changes from Ada 83 28.c/3 {AI05-0299-1} This subclause has been moved here from chapter 5, since it has mainly to do with subprograms. 28.d A function now creates an anonymous object. This is necessary so that controlled types will work. 28.e/2 {AI95-00318-02} We have clarified that a return statement applies to a callable construct, not to a callable entity. 28.f/2 {AI95-00318-02} There is no need to mention generics in the rules about where a return statement can appear and what it applies to; the phrase "body of a subprogram or generic subprogram" is syntactic, and refers exactly to "subprogram_body". Inconsistencies With Ada 95 28.f.1/3 {AI95-0416-1} {AI05-0005-1} {AI05-0050-1} Added an Implementation Permission allowing early raising of Constraint_Error if the result cannot fit in the ultimate object. This gives implementations more flexibility to do built-in-place returns, and is essential for limited types (which cannot be built in a temporary). However, it allows raising Constraint_Error in some cases where it would not be raised if the permission was not used. See Inconsistencies With Ada 2005 for additional changes. This case is potentially inconsistent with Ada 95, but a compiler does not have to take advantage of these permissions for any Ada 95 code, so there should be little practical impact. Incompatibilities With Ada 95 28.g/2 {AI95-00318-02} The entire business about return-by-reference types has been dropped. Instead, the expression of a return statement of a limited type can only be an aggregate or function_call (see 7.5). This means that returning a global object or type_conversion, legal in Ada 95, is now illegal. Such functions can be converted to use anonymous access return types by adding access in the function definition and return statement, adding .all in uses, and adding aliased in the object declarations. This has the advantage of making the reference return semantics much clearer to the casual reader. 28.h/2 We changed these rules so that functions, combined with the new rules for limited types (7.5), can be used as build-in-place constructors for limited types. This reduces the differences between limited and nonlimited types, which will make limited types useful in more circumstances. Extensions to Ada 95 28.i/2 {AI95-00318-02} The extended_return_statement is new. This provides a name for the object being returned, which reduces the copying needed to return complex objects (including no copying at all for limited objects). It also allows component-by-component construction of the return object. Wording Changes from Ada 95 28.j/2 {AI95-00318-02} The wording was updated to support anonymous access return subtypes. 28.k/2 {AI95-00318-02} The term "return expression" was dropped because reviewers found it confusing when applied to the default expression of an extended_return_statement. 28.l/2 {AI95-00344-01} {AI95-00416-01} Added accessibility checks to class-wide return statements. These checks could not fail in Ada 95 (as all of the types had to be declared at the same level, so the tagged type would necessarily have been at the same level as the type of the object). 28.m/2 {AI95-00402-01} {AI95-00416-01} Added accessibility checks to return statements for types with access discriminants. Since such types have to be limited in Ada 95, the expression of a return statement would have been illegal in order for this check to fail. Inconsistencies With Ada 2005 28.n/3 {AI05-0050-1} Correction: The Implementation Permission allowing early raising of Constraint_Error was modified to remove the most common of these cases from the permission (returning an object with mutable discriminants, where the return object is created with one set of discriminants and then changed to another). (The permission was also widened to allow the early check for constrained functions when that constraint is wrong.) However, there still is an unlikely case where the permission would allow an exception to be raised when none would be raised by the canonical semantics (when a return statement is abandoned). These changes can only remove the raising of an exception (or change the place where it is raised) compared to Ada 2005, so programs that depend on the previous behavior should be very rare. 28.o/3 {AI05-0051-1} {AI05-0234-1} Correction: Accessibility checks for access discriminants now depend on the master of the call rather than the point of declaration of the function. This will result in cases that used to raise Program_Error now running without raising any exception. This is technically inconsistent with Ada 2005 (as defined by Amendment 1), but it is unlikely that any real code depends on the raising of this exception. 28.p/3 {AI05-0073-1} Correction: Added a tag check for functions returning anonymous access-to-tagged types, so that dispatching of tag-indeterminate function works as expected. This is technically inconsistent with Ada 2005 (as defined by Amendment 1), but as the feature in question was newly added to Ada 2005, there should be little code that depends on the behavior that now raises an exception. Incompatibilities With Ada 2005 28.q/3 {AI05-0053-1} {AI05-0277-1} Correction: The aliased keyword can now only appear on extended return objects with an immutably limited type. Other types would provide a way to get an aliased view of an object that is not necessarily aliased, which would be very bad. This is incompatible, but since the feature was added in Ada 2005, the keyword had no defined meaning in Ada 2005 (a significant oversight), and most sensible uses involve immutably limited types, it is unlikely that it appears meaningfully in existing programs. 28.r/3 {AI05-0103-1} Correction: Added wording to require static matching for unconstrained access types in extended return statements. This disallows adding or omitting null exclusions, and adding access constraints, in the declaration of the return object. While this is incompatible, the incompatible cases in question are either useless (access constraints - the constraint can be given on an allocator if necessary, and still must be given there even if given on the return object) or wrong (null exclusions - null could be returned from a function declared to be null excluding), so we expect them to be extremely rare in practice. Extensions to Ada 2005 28.s/3 {AI05-0015-1} {AI05-0144-2} The return object of an extended_return_statement can be declared constant; this works similarly to a constant object declaration. 28.t/3 {AI05-0032-1} Added wording to allow the return_subtype_indication to have a specific type if the return subtype of the function is class-wide. Specifying the (specific) type of the return object is awkward without this change, and this is consistent with the way allocators work. Wording Changes from Ada 2005 28.u/3 {AI05-0024-1} Correction: Corrected the master check for tags since the masters may be for different tasks and thus incomparable. 28.v/3 {AI05-0058-1} Correction: Corrected the wording defining returns for extended_return_statements, since leaving by an exit or goto is considered "normal" completion of the statement. 28.w/3 {AI05-0205-1} {AI05-0277-1} Correction: Added the extended_return_object_declaration to make other rules easier to write and eliminate the problem described in AI05-0205-1. Wording Changes from Ada 2012 28.x/4 {AI05-0097-1} Corrigendum: Clarified the wording so that it is clear where the tag of the return object comes from. While a literal reading of the original Ada 2012 rule could have caused some weird results (by using some nearby subtype_indication to provide the tag in the case of a simple_return_statement, such a reading would be so unlike the rest of the language that we do not believe anyone would ever have thought it was intended. As such, we do not believe any implementation ever did this wrong (at least because of the old wording), and thus do not document this as a possible inconsistency. 6.5.1 Nonreturning Procedures 1/3 {AI95-00329-01} {AI95-00414-01} {AI05-0229-1} Specifying aspect No_Return to have the value True indicates that a procedure cannot return normally[; it may propagate an exception or loop forever]. 1.a/3 Discussion: Aspect No_Deposit will have to wait for Ada 2020. :-) Paragraphs 2 and 3 were moved to Annex J, "Obsolescent Features". Static Semantics 3.1/3 {AI05-0229-1} For a procedure or generic procedure, the following language-defined representation aspect may be specified: 3.2/3 No_Return The type of aspect No_Return is Boolean. When aspect No_Return is True for an entity, the entity is said to be nonreturning. 3.3/3 If directly specified, the aspect_definition shall be a static expression. [This aspect is never inherited;] if not directly specified, the aspect is False. 3.a/3 Aspect Description for No_Return: A procedure will not return normally. 3.4/3 {AI05-0229-1} If a generic procedure is nonreturning, then so are its instances. If a procedure declared within a generic unit is nonreturning, then so are the corresponding copies of that procedure in instances. Legality Rules 4/3 {AI95-00329-01} {AI95-00414-01} {AI05-0229-1} Aspect No_Return shall not be specified for a null procedure nor an instance of a generic unit. 4.a/2 Reason: A null procedure cannot have the appropriate nonreturning semantics, as it does not raise an exception or loop forever. 4.b/3 Ramification: {AI05-0229-1} The procedure can be abstract. If a nonreturning procedure is renamed (anywhere) calls through the new name still have the nonreturning semantics. 5/2 {AI95-00329-01} {AI95-00414-01} A return statement shall not apply to a nonreturning procedure or generic procedure. 6/2 {AI95-00414-01} A procedure shall be nonreturning if it overrides a dispatching nonreturning procedure. In addition to the places where Legality Rules normally apply (see 12.3), this rule applies also in the private part of an instance of a generic unit. 6.a/2 Reason: This ensures that dispatching calls to nonreturning procedures will, in fact, not return. 7/2 {AI95-00414-01} If a renaming-as-body completes a nonreturning procedure declaration, then the renamed procedure shall be nonreturning. 7.a/2 Reason: This ensures that no extra code is needed to implement the renames (that is, no wrapper is needed) as the body has the same property. Paragraph 8 was deleted. Dynamic Semantics 9/2 {AI95-00329-01} {AI95-00414-01} If the body of a nonreturning procedure completes normally, Program_Error is raised at the point of the call. 9.a/2 Discussion: Note that there is no name for suppressing this check, since the check represents a bug, imposes no time overhead, and minimal space overhead (since it can usually be statically eliminated as dead code). 9.b/2 Implementation Note: If a nonreturning procedure tries to return, we raise Program_Error. This is stated as happening at the call site, because we do not wish to allow the procedure to handle the exception (and then, perhaps, try to return again!). However, the expected run-time model is that the compiler will generate raise Program_Error at the end of the procedure body (but not handleable by the procedure itself), as opposed to doing it at the call site. (This is just like the typical run-time model for functions that fall off the end without returning a value). The reason is indirect calls: in P.all(...);, the compiler cannot know whether P designates a nonreturning procedure or a normal one. Putting the raise Program_Error in the procedure's generated code solves this problem neatly. 9.c/2 Similarly, if one passes a nonreturning procedure to a generic formal parameter, the compiler cannot know this at call sites (in shared code implementations); the raise-in-body solution deals with this neatly. Examples 10/3 {AI95-00433-01} {AI05-0229-1} procedure Fail(Msg : String) -- raises Fatal_Error exception with No_Return; -- Inform compiler and reader that procedure never returns normally Extensions to Ada 95 10.a/2 {AI95-00329-01} {AI95-00414-01} Pragma No_Return is new. Extensions to Ada 2005 10.b/3 {AI05-0229-1} Aspect No_Return is new; pragma No_Return is now obsolescent. 6.6 Overloading of Operators 1 An operator is a function whose designator is an operator_symbol. [Operators, like other functions, may be overloaded.] Name Resolution Rules 2 Each use of a unary or binary operator is equivalent to a function_call with function_prefix being the corresponding operator_symbol, and with (respectively) one or two positional actual parameters being the operand(s) of the operator (in order). 2.a/3 To be honest: {AI05-0299-1} We also use the term operator (in Clause 4 and in 6.1) to refer to one of the syntactic categories defined in 4.5, "Operators and Expression Evaluation" whose names end with "_operator:" logical_operator, relational_operator, binary_adding_operator, unary_adding_operator, multiplying_- operator, and highest_precedence_operator. 2.b/3 Discussion: {AI05-0005-1} This equivalence extends to uses of function_call in most other language rules. However, as often happens, the equivalence is not perfect, as operator calls are not a name, while a function_call is a name. Thus, operator calls cannot be used in contexts that require a name (such as a rename of an object). A direct fix for this problem would be very disruptive, and thus we have not done that. However, qualifying an operator call can be used as a workaround in contexts that require a name. Legality Rules 3/3 {AI05-0143-1} The subprogram_specification of a unary or binary operator shall have one or two parameters, respectively. The parameters shall be of mode in. A generic function instantiation whose designator is an operator_symbol is only allowed if the specification of the generic function has the corresponding number of parameters, and they are all of mode in. 4 Default_expressions are not allowed for the parameters of an operator (whether the operator is declared with an explicit subprogram_specification or by a generic_instantiation). 5 An explicit declaration of "/=" shall not have a result type of the predefined type Boolean. Static Semantics 6/3 {AI05-0128-1} An explicit declaration of "=" whose result type is Boolean implicitly declares an operator "/=" that gives the complementary result. 6.a/3 Discussion: {AI05-0128-1} A "/=" defined by this rule is considered user-defined, which means that it will be inherited by a derived type. "User-defined" means "not language-defined" for the purposes of inheritance, that is anything other than predefined operators. NOTES 7 10 The operators "+" and "-" are both unary and binary operators, and hence may be overloaded with both one- and two-parameter functions. Examples 8 Examples of user-defined operators: 9 function "+" (Left, Right : Matrix) return Matrix; function "+" (Left, Right : Vector) return Vector; -- assuming that A, B, and C are of the type Vector -- the following two statements are equivalent: A := B + C; A := "+"(B, C); Extensions to Ada 83 9.a Explicit declarations of "=" are now permitted for any combination of parameter and result types. 9.b Explicit declarations of "/=" are now permitted, so long as the result type is not Boolean. Wording Changes from Ada 2005 9.c/3 {AI05-0128-1} Correction: Corrected the wording so that only explicit declarations of "=" cause an implicit declaration of "/="; otherwise, we could get multiple implicit definitions of "/=" without an obvious way to chose between them. 9.d/3 {AI05-0143-1} Added wording so that operators only allow parameters of mode in. This was made necessary by the elimination elsewhere of the restriction that function parameters be only of mode in. 6.7 Null Procedures 1/2 {AI95-00348-01} A null_procedure_declaration provides a shorthand to declare a procedure with an empty body. Syntax 2/3 {AI95-00348-01} {AI05-0183-1} null_procedure_declaration ::= [overriding_indicator] procedure_specification is null [aspect_specification]; Legality Rules 2.1/3 {AI05-0177-1} If a null_procedure_declaration is a completion, it shall be the completion of a subprogram_declaration or generic_subprogram_declaration. The profile of a null_procedure_declaration that completes a declaration shall conform fully to that of the declaration. Static Semantics 3/3 {AI95-00348-01} {AI05-0177-1} {AI05-0264-1} A null_procedure_declaration declares a null procedure. A completion is not allowed for a null_procedure_declaration; however, a null_procedure_declaration can complete a previous declaration. 3.a/2 Reason: There are no null functions because the return value has to be constructed somehow; a function that always raises Program_Error doesn't seem very useful or worth the complication. Dynamic Semantics 4/2 {AI95-00348-01} The execution of a null procedure is invoked by a subprogram call. For the execution of a subprogram call on a null procedure, the execution of the subprogram_body has no effect. 4.a/2 Ramification: Thus, a null procedure is equivalent to the body 4.b/2 begin null; end; 4.c/2 with the exception that a null procedure can be used in place of a procedure specification. 5/3 {AI95-00348-01} {AI05-0177-1} The elaboration of a null_procedure_declaration has no other effect than to establish that the null procedure can be called without failing the Elaboration_Check. Examples 6/2 {AI95-00433-01} procedure Simplify(Expr : in out Expression) is null; -- see 3.9 -- By default, Simplify does nothing, but it may be overridden in extensions of Expression Extensions to Ada 95 6.a/2 {AI95-00348-01} Null procedures are new. Extensions to Ada 2005 6.b/3 {AI05-0177-1} A null_procedure_declaration can now be a completion. 6.c/3 {AI05-0183-1} An optional aspect_specification can be used in a null_procedure_declaration. This is described in 13.1.1. 6.8 Expression Functions 1/3 {AI05-0177-1} An expression_function_declaration provides a shorthand to declare a function whose body consists of a single return statement. Syntax 2/4 {AI95-0177-1} {AI95-0147-1} expression_function_declaration ::= [overriding_indicator] function_specification is (expression) [aspect_specification]; | [overriding_indicator] function_specification is aggregate [aspect_specification]; Name Resolution Rules 3/4 {AI05-0177-1} {AI95-0147-1} The expected type for the expression or aggregate of an expression_function_declaration is the result type (see 6.5) of the function. Legality Rules 4/3 {AI05-0177-1} If an expression_function_declaration is a completion, it shall be the completion of a subprogram_declaration or generic_subprogram_declaration. The profile of an expression_function_declaration that completes a declaration shall conform fully to that of the declaration. 5/4 {AI05-0177-1} {AI95-0147-1} If the result subtype has one or more unconstrained access discriminants, the accessibility level of the anonymous access type of each access discriminant, as determined by the expression or aggregate of the expression_function_declaration, shall not be statically deeper than that of the master that elaborated the expression_function_- declaration. 5.a/3 Ramification: This can only fail if the discriminant is an access to a part of a non-aliased parameter, as there can be no local declarations here. 5.b/4 Discussion: {AI12-0005-1} We don't need to repeat any of the other Legality Rules for return statements since none of them can fail here: the implicit return statement has to apply to this function (and isn't nested in something), there clearly is a return statement in this function, and the static class-wide accessibility check cannot fail as a tagged type cannot be declared locally in an expression function. Static Semantics 6/4 {AI05-0177-1} {AI05-0264-1} {AI95-0147-1} An expression_function_declaration declares an expression function. The return expression of an expression function is the expression or aggregate of the expression_function_declaration. A completion is not allowed for an expression_- function_declaration; however, an expression_function_declaration can complete a previous declaration. Dynamic Semantics 7/4 {AI05-0177-1} {AI05-0262-1} {AI95-0147-1} The execution of an expression function is invoked by a subprogram call. For the execution of a subprogram call on an expression function, the execution of the subprogram_body executes an implicit function body containing only a simple_return_statement whose expression is the return expression of the expression function. 7.a/3 Discussion: The last sentence effectively means that all of the dynamic wording in 6.5 applies as needed, and we don't have to repeat it here. 8/3 {AI05-0177-1} The elaboration of an expression_function_declaration has no other effect than to establish that the expression function can be called without failing the Elaboration_Check. Examples 9/3 {AI05-0177-1} function Is_Origin (P : in Point) return Boolean is -- see 3.9 (P.X = 0.0 and P.Y = 0.0); Extensions to Ada 2005 9.a/3 {AI05-0177-1} Expression functions are new in Ada 2012. Extensions to Ada 2012 9.b/4 {AI12-0157-1} A aggregate can directly be the return expression of an expression function. This eliminates the double parentheses that otherwise would be necessary.