6.4.1 Parameter Associations

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.

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

To be honest: {AI05-0118-1} For positional parameters, the “corresponding position” is calculated after any transformation of prefixed views. 

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. 

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.

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

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. 

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: 

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. 

Reason: These rules are needed in order to ensure that a well-defined parameter value is passed. 

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. 

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. 

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

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

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. 

Reason: This exposes known renamings of slices, indexing, and so on to this definition. In particular, if we have 

then C and S(1) are known to denote the same object.

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:

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

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: 

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.

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. 

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

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.

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: 

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. 

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

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. 

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

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. 

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

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. 

Ramification: We do not check expressions that are evaluated only because of a component initialized by default in an aggregate (via <>). 

Discussion: We are always allowing sliding, even for [in] out by-reference parameters. 

Ramification: The conversion mentioned here is a value conversion. 

Reason: This preserves the Language Design Principle that an object of an access type is always initialized with a “reasonable” value. 

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. 

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

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.

Reason: This ensures that no part of an object of such a type can become “de-initialized” by being part of an out parameter. 

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. 

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. 

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

Ramification: The conversions mentioned above during parameter passing might raise Constraint_Error — (see 4.6). 

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.

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.

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. 

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

{AI05-0299-1} We have eliminated the subclause on Default Parameters, as it is subsumed by earlier subclauses. 

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

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

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

{AI05-0102-1} Correction: Moved implicit conversion Legality Rule to 8.6.

{AI05-0118-1} Correction: Added a definition for positional parameters, as this is missing from Ada 95 and later.

{AI05-0142-4} Rules have been added defining the legality and dynamic checks needed for explicitly aliased parameters (see 6.1).

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

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

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