AI22-0046-1

!standard 4.9(17.3/5)                                    22-06-23  AI22-0046-1/02

!class binding interpretation 22-03-25

!status Corrigendum 1-2022 22-06-23

!status WG9 Approved 22-10-18

!status ARG Approved 15-0-0  22-06-23

!status work item 22-03-25

!status received 22-03-25

!priority Low

!difficulty Easy

!qualifier Omission

!subject Statically names misses some cases

!summary

For a name N that statically names an object (but does not statically denote any object),

• the target name symbol statically names an object if it names N;
• a renaming of N statically names an object.

!issue

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.

Specifically, in:

@ statically denotes the object A. However, in:

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

!recommendation

Rewrite the definition of statically names to eliminate these bizarre cases.

!wording

Modify 4.9(17.3/5):

• {is a target_name in an assignment_statement whose variable_name statically names some entity;

• denotes a renaming_declaration with a name that statically names the renamed entity;

• } is a selected_component whose prefix statically names an object, there is no implicit dereference of the prefix, and the selector_name does not denote a component_declaration occurring within a variant_part; or

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.

!discussion

A similar problem occurs for renames. So, for instance, if we have:

C does not statically name an object. While if we had:

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:

• is a direct_name, expanded name, or character_literal, and it denotes a declaration other than a renaming_declaration; or

• is an attribute_reference whose prefix statically denotes some entity.

A name statically denotes an entity if it denotes the entity and it:

• directly statically denotes the entity;

• is a target_name (see 5.2.1) in an assignment_statement whose variable_name   statically denotes some entity; or

• denotes a renaming_declaration with a name that statically denotes the renamed entity.

A name statically names an object if it:

• directly statically denotes the declaration of an object;
• is a target_name in an assignment_statement whose variable_name statically names some entity;
• denotes a renaming_declaration with a name that statically names the renamed entity;
• is a selected_component whose prefix statically names an object, there is no implicit  dereference of the prefix, and the selector_name does not denote a component_declaration   occurring within a variant_part; or

• is an indexed_component whose prefix statically names an object, there is no implicit   dereference of the prefix, the object is statically constrained, and the index expressions of the object are static and have values that are within the range of the index constraint.

!example

(See Issue and Discussion.)

!corrigendum 4.9(17.3/5)

@drepl

@xbullet{is a @fa{selected_component} whose prefix statically names an object, there is no implicit dereference of the prefix, and the @fa{selector_name} does not denote a @fa{component_declaration} occurring within a @fa{variant_part}; or}

@dby

@xbullet{is a @fa{target_name} in an @fa{assignment_statement} whose @fa{variable_name} statically names some entity;}

@xbullet{denotes a @fa{renaming_declaration} with a @fa{name} that statically names the renamed entity;}

@xbullet{is a @fa{selected_component} whose prefix statically names an object, there is no implicit dereference of the prefix, and the @fa{selector_name} does not denote a @fa{component_declaration} occurring within a @fa{variant_part}; or}

!ACATS test

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.

!appendix

This AI in partially in response to ARG Github Issue #6 (https://github.com/Ada-Rapporteur-Group/User-Community-Input/issues/6).

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