!standard 4.9(17.3/5) 22-06-16 AI22-0046-1/01
!class binding interpretation 22-03-25
!status work item 22-03-25
!status received 22-03-25
!subject Statically names misses some cases
For a name N that statically names an object (but does not statically denote any object),
AI12-0322-1 added text so that the target name symbol '@' can statically denote an entity if the target statically denotes an entity. However, we did not extend that to statically naming an entity.
A := @ + 1;
@ statically denotes the object A. However, in:
A.B := @ + 1;
@ does not statically name an object, even if A statically denotes an object, and B is a component of that object, so that A.B statically names an object.
Why? A.B does not statically denote an object, so 4.9(16.1/5) does not apply, and thus @ does not statically denote an object (so 4.9(17.2/5) does not apply). @ is neither a selected_component nor an indexed_component, so 4.9(17.3-4/5) don't apply, either. We are talking about an object, so 4.9(17.5/5) doesn't apply. So none of the rules apply, and we must conclude that @ in the above does not statically name anything (even though the underlying name A.B does statically name an object).
This seems inconsistent.
Rewrite the definition of statically names to eliminate these bizarre cases.
Add an AARM Note after 4.9(17.4/5):
AARM To Be Honest: For a renaming or target_name whose name statically denotes an object, there are multiple ways to determine that the renaming or target_name statically names an object. The wording seemed clearer written this way; refactoring would have required the introduction of yet another term.
A similar problem occurs for renames. So, for instance, if we have:
C : renames A.B;
C does not statically name an object. While if we had:
D : renames A;
then D.B does statically name an object.
The target name symbol case matters as "statically names" is used in the anti-order dependence checks of 6.4. That means, as written, using '@' could be used to evade a bad order check. That is the sort of perverse incentive (or disincentive, depending on your feelings) that we try to avoid in Ada.
The renames case can come up in any rule that uses "statically names".
Fully refactored wording would require the introduction of another term. This would look something like:
A name directly statically denotes an entity if it denotes the entity and it:
A name statically denotes an entity if it denotes the entity and it:
A name statically names an object if it:
(See Issue and Discussion.)
An ACATS B-Test could be constructed using the target name symbol and an illegal order dependence. Probably some other rules could be tested using renames of statically named objects.
This AI in partially in response to ARG Github Issue #6 (https://github.com/Ada-Rapporteur-Group/User-Community-Input/issues/6).