Suggested enhancements to the wording in 3.10.2 about "tied" accessibility levels

[sttaft]

Eric Botcazou recently ventured into the heart of darkness (RM 3.10.2) to implement the rules relating to "tied" accessibility levels. He provided the following information about what he learned along the way, including some suggestions for improving the RM and AARM wording.

-Tuck

------- from Eric Botcazou ------

I have been trying over the last few days to understand the last example of AI12-0345 (the AI introducing the concept of accessibility levels being tied to each other). IMO the example is nontrivial to grasp, let alone to implement correctly, but I think that I get it now. However, a major source of difficulty is IMO to understand what this new relation defined on accessibility levels is about, since the AARM is quite terse about it. Therefore, assuming that it will be kept for the future, I'd suggest making the life of the next reader easier by adding a "Ramification" note right after 3.10.2(5) to elaborate a bit on it (and also possibly adding a small clarification to 5 itself). FWIW here's what I have written in my notes:

3.10.2(5): Each master, and each entity and view created by it, has an
accessibility level; when two levels are defined to be the same{ in a
particular construct by one of the following rules}, the accessibility
levels of the two associated entities are said to be tied to each other.
Accessibility levels are defined as follows:

{5.a Ramification: The relation thus defined on accessibility levels is an
explicitly symmetric and transitive form of the "defined to be the same"
relation. It is defined statically for the constituents of a particular
construct in the program and holds only in the context of this construct.}
but a better wording can probably be devised.

I'd also suggest making a small addition to the "21.b Ramification" note:

21.b Ramification:{ Note the "considered" instead of "defined" to be the same.}
This rule only applies when the level of an explicitly aliased parameter of a
function is compared to that of the return object of the function. [...]

[sttaft]

Another related issue: AI12-0372-1 has a small typo in the following paragraph:

Copy's parameter has the same accessibility as is the master of the
call of Copy (by 3.10.2(7/5)). Therefore the accessibility of the parameter of
Copy is tied to the master of the call of Copy. We know by applying the
second part of 3.10.2(10.5/5) that the master of the call of Make is therefore
the master of the call of Copy. By applying the first part of 3.10.2(10.5/5),
the master of the call of Copy is that of Func. Now we can apply 3.10.2(10/5)
again then know by the new rule that that the level of Y is statically deeper
than the master of the call of Func, making the call at (3) illegal.

The last reference to 3.10.2(10/5) should almost certainly be 3.10.2(10.5/5).

[sttaft]

Further comments from Eric Botcazou, relating to the example in AI12-0372-1:

The 3.10.2(10.5/5) and (21.1/5) rules explicitly mention the result or return object of the enclosing function at stake, here Copy , so they would need to be applied to the call on Make inside Copy. Moreover, the second rule is not a "defined to be the same" rule, so it cannot be used to tie the accessibility levels of the aliased actual and the return object after "going inside" of Copy , which would make it possible to apply the second part of (10.5/5) and conclude that the master of the call on Make is the master of the call on Copy. So IMO the chain of "defined to be the same" rules needed to establish the tying of accessibility levels required to leverage the second part of (10.5/5) is not crystal clear, although I agree that the whole reasoning based on the presence of explicit aliased parameters is pretty solid.

[sttaft]

Eric also noticed the following: Ada 2022 creates a special case for functions with an explicitly aliased formal that return an object of an elementary type (AI12-0402-1). Calls on these functions don't have any accessibility checks related to the use of the result, per the new wording of 3.10.2(10.2/5). This means that ACATS test B641002 has three lines marked as "ERROR (C)", specifically lines 305, 308, and 309, and these three should no longer be considered errors in Ada 2022.

[sttaft]

One additional note. Eric has found a case where the change to exempt elementary types by AI12-0402-1 for 3.10.2(10.2) should probably be generalized to cover 3.10.2(10.5) as well, as follows:

If the call itself defines the result of a function F, or has an accessibility level that is tied to the result of such a function F,{ where F is a function with a composite or anonymous access result type,} then the master of the call is that of the master of the call invoking F;

It is somewhat silly to carry the master of the call into a function returning a scalar type, when we have exempted such functions in paragraph 10.2 from having the master of the call defined by the target.

[ARG-Editor]

Github Issue #156 contains the following suggestions:

3.10.2(5): Each master, and each entity and view created by it, has an
accessibility level; when two levels are defined to be the same{ in a
particular construct by one of the following rules}, the accessibility
levels of the two associated entities are said to be tied to each other.
Accessibility levels are defined as follows:

{5.a Ramification: The relation thus defined on accessibility levels is an
explicitly symmetric and transitive form of the "defined to be the same"
relation. It is defined statically for the constituents of a particular
construct in the program and holds only in the context of this construct.}

21.b Ramification:{ Note the "considered" instead of "defined" to be the same.}
This rule only applies when the level of an explicitly aliased parameter of a
function is compared to that of the return object of the function. [...]

The normative wording change seems unnecessary with the suggested AARM note,
and the note should directly mention "tied":

{5.a Ramification: The tied relation thus defined on accessibility levels is an
explicitly symmetric and transitive relation. It is defined statically
for the constituents of a particular construct in the program and holds
only in the context of this construct.}

The other note also should mention "tied", and as it is the least important part
of this note, it should go at the end:

21.b Ramification:
This rule only applies when the level of an explicitly aliased parameter of
a function is compared to that of the return object of the function. If a
value designating the explicitly aliased parameter is created and stored
in a stand-alone object or passed as a parameter, this special property is
lost (even for the dynamic accessibility of anonymous access types in these
contexts).{ Note the "considered" instead of "defined" to be the same;
this rule does not cause "tied" accessibility levels.}

These changes were made to the draft RM.

[ARG-Editor]

The comments on AI12-0372-1 are, sadly, irrelevant: we do not change existing AIs after they are approved by WG 9. (And surely not AIs from completed standardization activities. If a correction is needed, that is done in a new AI. But in this case, there is no correction needed beyond the discussion and example, and even if we had an AI that fixed those, it wouldn't show up to anyone following to the existing AI. So there doesn't appear to be anything that we can usefully do with these comments.

[ARG-Editor]

The ACATS comments have been added to the lengthy list of changes needed for ACATS 5.0. (The ACATS for Ada 2022, not yet created.)

The rule suggestion for 3.10.2(10.5/5) seems to run into changes needed for aliased returns, so I've referred it to AI22-0075-1. (If the author of that AI wants to handle it separately, he can.)

With that, all of the issues herein have been handled or assigned, so this Issue has been closed.