6.5 Return Statements

To be honest: The same applies to generic functions. 

Reason: {AI95-00318-02} The requirement that a function body has to have at least one return statement return_statement is a “helpful” restriction. There has was been some interest in lifting this restriction, or allowing a raise statement to substitute for the return statement return_statement. However, there was enough interest in leaving it as is that we decided not to change it. 

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. 

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. 

This paragraph was deleted.Discussion: {AI05-0188-1} In other words, if limited, the expression must produce a “new” object, rather than being the name of a preexisting object (which would imply copying).

Discussion: {AI05-0032-1} {AI05-0051-1} If We know that 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 rules must be satisfied. Similarly, if the result subtype is unconstrained, then either the return_subtype_indication (if any) is constrained, or there must be an expression.

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

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

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

Ramification: The conversion might raise Constraint_Error — (see 4.6). 

Proof: This is specified by the rules in 9.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. 

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.

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

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. 

Ramification: {AI95-00318-02} This is true even if the tag of the return expression is different. 

Reason: {AI95-00318-02} These rules ensure 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, if nonlimited, allows the caller to allocate the appropriate amount of space to hold the value being returned (assuming there are no discriminants). 

Ramification: The above rules are such that there are no "Ada 83" types other than those containing tasks that are return-by-reference. This helps to minimize upward incompatibilities relating to return-by-reference.

Discussion: {AI95-00316-01} This rule was unnecessarily confusing, and the parenthetical remark "(or a value with an associated object, see 6.2)" was added — and then the entire concept was deleted.

The return-by-reference types are all limited types except those that are limited only because of a limited private type with a nonlimited untagged full type.

Reason: This check can often be performed at compile time. It is defined to be a run-time check to avoid generic contract model problems. In a future version of the standard, we anticipate that function return of a local variable will be illegal for all limited types, eliminating the need for the run-time check except for dereferences of an access parameter. 

This paragraph was deleted.Ramification: The assignment operation does the necessary value adjustment, as described in 7.6, “Assignment and Finalization”. 7.6.1 describes when the anonymous constant is finalized. 

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. 

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

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.

On the other hand, given 

The need for including subcomponents in this check is illustrated by the following example: 

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.

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.

Reason: {AI95-00416-01} {AI05-0050-1} Without such a permission, it would be very difficult to implement “ built-in-place build-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 Such an exception is not handleable within the function, because in the return-by-copy case, the constraint check to verify that the result satisfies the constraints of the object being initialized happens after the function returns, and we want the semantics to change as little as possible when switching between return-by-copy and build-in-place. This implies further that upon detecting such a situation, the implementation may need to simulate a goto to a point outside any local exception handlers prior to raising the exception. 

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. This permission is allowed during the evaluation of the expression of an extended_return_statement, because the return_subtype_indication may be unconstrained and the expression then would provide the constraints.

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

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

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

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. 

This clause has been moved here from chapter 5, since it has mainly to do with subprograms.

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

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

{AI95-00318-02} There is no need to mention generics in the rules about where a return statement 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”.

{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 an 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. 

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

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. 

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

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

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

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

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

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

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

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

{AI05-0053-1} Correction: Eliminated the aliased keyword from the syntax of extended_return_statements, as this would provide a way to get an aliased view of an object that is not necessarily aliased. This is technically incompatible, but since the feature was added in Ada 2005 and not widely implemented, it is very unlikely that it appears in existing programs.

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

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

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

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

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