Version 1.1 of ai12s/ai12-0277-1.txt

Unformatted version of ai12s/ai12-0277-1.txt version 1.1
Other versions for file ai12s/ai12-0277-1.txt

!standard 13.11(21)          18-05-11 AI12-0277-1/01
!standard 13.11.4(21/3)
!standard 13.11.4(31/3)
!class binding interpretation 18-05-11
!status work item 18-05-11
!status received 18-05-10
!priority Low
!difficulty Easy
!qualifier Clarification
!subject "accessibility level of the body of F"
!summary
The accessibility level of an explicitly aliased parameter is the same as that of a normal parameter other than in the special cases called out in 3.10.2(19.2/4).
!question
Consider the following program:
type Integer_Access is access all Integer;
function Inner(Value : aliased in out Integer) return Integer_Access is begin return Value'access; -- OK (No.) end Inner;
function Outer return Integer_Access is Value : aliased Integer := 0; begin return Inner(Value); -- OK. end Outer;
Ptr : Integer_Access := Outer; -- Oops, dangling.
Value'Access is OK since 3.10.2(19.2/4) says that
... for statically comparing with the level of other entities, an explicitly aliased parameter of F is considered to have the accessibility level of the body of F.
...and Integer_Access and the body of Inner have the same level.
Inner(Value) is OK since 6.4.1(6.4/3) says:
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.
...and the master of the call here is the contents of Outer, same as Value.
However, this leaves Ptr assigned to an access to a non-existent object. Is this analysis correct? (No.)
!recommendation
(See Summary.)
!wording
Modify 3.10.2(19.2/4):
Inside a return statement that applies to a function or generic function F, or the return expression of an expression function F, when determining whether the accessibility level of an explicitly aliased parameter of F is statically deeper than the level of the return object of F, the level of the return object is considered to be the same as that of the level of the explicitly aliased parameter; for statically comparing with the level of other entities, an explicitly aliased parameter of F is considered to have the accessibility level of a parameter of F that is not explicitly aliased.
!discussion
The wording in 3.10.2(19.2/4) is ambiguous. The questioner read the phrase "accessibility level of the body of F" as meaning the "accessibility level of the declaration of the body of F", whereas it also can be read to mean the "accessibility level of the contents of the body of F" (or possibly the invocation of F - as in 3.10.2(7/4)).
AI05-0235-1, which created this wording (as well as the majority of the current wording in 3.10.2(7/4)), makes it crystal-clear what was intended. The summary of that AI says:
(2) Explicitly aliased parameters have special accessibility only within the return statement of a function; otherwise, they have the same accessibility as "normal" parameters.
This makes it clear that the second interpretation was intended, and that interpretation makes the "Value'Access" illegal, as Value is more nested than Integer_Access. (Note that the special case doesn't apply here, even though this is a return statement -- we're not comparing with the level of the return object but rather the level of some other declaration.)
It's important to note that the level to check prior to AI05-0235-1 was indeed the first intrepretation; we would not have changed the wording had that interpretation been appropriate.
----
We considered a wide variety of clarifications to this wording. We could just add an AARM Note:
To Be Honest: We mean the level associated with the invocation of the body (and thus of the direct contents of the body) and not the level of the declaration of the body.
Or we could leave the wording alone other than to clarify what was meant:
... for statically comparing with the level of other entities, an explicitly aliased parameter of F is considered to have the accessibility level of the body of F Redundant[, the same as a parameter which is not explicitly aliased].
But if we're going to change the wording at all, why not change it to say exactly what was meant. One way to do that is to echo the wording of 3.10.2(7/4) [which this wording originally was meant to be an add-on of, but it was modified during the ARG meeting that approved it to make it totally separate]:
... for statically comparing with the level of other entities, an explicitly aliased parameter of F is considered to have the accessibility level of the master representing the invocation of F.
To Be Honest: We use "invocation of" in the parameter case as a master is formally an execution of something. But we mean this to be interpreted statically (as the body of the function F).
The AARM note is also copied from 3.10.2(7/4). But that makes the wording somewhat unclear:
The original proposed wording in the e-mail attached to AI05-0235-1 was:
... for statically comparing with the level of other entities, an explicitly aliased parameter of F is considered to have the accessibility level of a local object of F.
But it seems best to encourage the fact that all parameters are the same other than in one special case:
... for statically comparing with the level of other entities, an explicitly aliased parameter of F is considered to have the accessibility level of a non-explicitly-aliased parameter of F.
"non-explicitly-aliased" is a mouthful. Thus we rearranged it to get the wording proposed above.
!ASIS
No ASIS effect.
!ACATS test
Since a respected ARG member and compiler implementer sent in this question, based on a customer bug report, an ACATS B-Test (B3A2018) was constructed to check this case and the similar one discussed in AI05-0235-1.
!appendix

****************************************************************

Questions? Ask the ACAA Technical Agent