AI22-0054-1/02

AI22-0054-1

!standard 4.1.4(6/5) 23-01-23 AI22-0054-1/02

!class binding interpretation 22-10-28

!status ARG Approved 15-0-0 23-01-19

!status work item 22-10-28

!status received 22-05-09

!priority Low

!difficulty Easy

!qualifier Omission

!subject Ambiguous prefix for the Result attribute

!summary

Attributes that are only allowed inside of the construct named in the prefix can use that limitation as a Name Resolution Rule.

!issue

Consider a package where multiple overloaded functions are declared:

package Pkg is
function F (X : Integer) return Integer;
function F (X : Float) return Integer with Post => F'Result /= 0;
end Pkg;

It appears that the prefix of the attribute Result is ambiguous, as attribute prefixes have to be resolved without any context.

This seems to make it impossible to write postconditions for overloaded functions if the Result of the function is needed in the postcondition. We can't have intended that.

!recommendation

(See Summary.)

!wording

Modify 4.1.4(6/5):

In an attribute_reference that is not a reduction_attribute_reference, if the attribute_designator is for an attribute defined for (at least some) objects of an access type, then the prefix is never interpreted as an implicit_dereference; otherwise (and for all range_attribute_references and reduction_attribute_references), if there is a prefix and the type of the name within the prefix is of an access type, the prefix is interpreted as an implicit_dereference. Similarly, if the attribute_designator is for an attribute defined for (at least some) functions, then the prefix is never interpreted as a parameterless function_call; otherwise (and for all range_attribute_references and reduction_attribute_references), if there is a prefix and the prefix consists of a name that denotes a function, it is interpreted as a parameterless function_call. {Any requirement that a given attribute_designator may only be referenced from within a construct denoted by the prefix is considered a Name Resolution Rule for the prefix.}

{AARM Discussion: Attributes that are subject to such "may only be referenced from within" requirements include the Caller and Result attributes. The Count attribute is not such an attribute; it only is required to be inside of the enclosing task containing the prefix.}

!discussion

AARM 4.1.4(6.d-6.h) specifically talk about how attributes do not resolve even when only one possible prefix is legal. So it is clear that the language rules as written intend for this example to be illegal.

We therefore have rewritten the resolution rule in order to allow a required context to be used for resolution. This affects only the Result and Caller attributes.

We had briefly thought that the Count attribute also would be affected, but it can be used outside of the entry that it names (it is only required to be inside of the enclosing task). This is good, since there is an Ada 83 ACATS test, specifically B87B26A (dated 1986), that requires that a Count attribute prefix is ambiguous if another declaration with the same name is visible. Presumably, all existing Ada compilers pass this test, so a change to the rule for the Count attribute would cause work for implementations (and for no obvious value).

!example

Note that this only applies to attributes that are required to be used inside of the construct that is named in the prefix. It does not apply just because the attribute is used inside of the construct named in the prefix. For instance, the following remains illegal as the prefix is ambiguous:

with System; use System;
package Pkg2 is
function F (X : Integer) return Integer;
function F (X : Float) return Integer with
Post => F'Address /= Null_Address; -- Illegal.
end Pkg2;

!corrigendum 4.1.4(6/5)

@drepl

In an @fa{attribute_reference} that is not a @fa{reduction_attribute_reference}, if the @fa{attribute_designator} is for an attribute defined for (at least some) objects of an access type, then the @fa{prefix} is never interpreted as an @fa{implicit_dereference}; otherwise

@fa{prefix} is never interpreted as a parameterless @fa{function_call}; otherwise (and for all @fa{range_attribute_reference}s and @fa{reduction_attribute_reference}s), if there is a @fa{prefix} and the @fa{prefix} consists of a @fa{name} that denotes a function, it is

interpreted as a parameterless @fa{function_call}.

@dby

(and for all @fa{range_attribute_reference}s and @fa{reduction_attribute_reference}s), if there is a @fa{prefix} and the type of the @fa{name} within the @fa{prefix} is of an access type, the @fa{prefix} is interpreted as an @fa{implicit_dereference}. Similarly, if the @fa{attribute_designator} is for an attribute defined for (at least some) functions, then the @fa{prefix} is never interpreted as a parameterless @fa{function_call}; otherwise (and for all @fa{range_attribute_reference}s and @fa{reduction_attribute_reference}s), if there is a @fa{prefix} and the @fa{prefix} consists of a @fa{name} that denotes a function, it is interpreted as a parameterless @fa{function_call}. Any requirement that a given @fa{attribute_designator} may only be referenced from within a construct denoted by the @fa{prefix} is considered a Name Resolution Rule for the @fa{prefix}.

!ACATS test

An ACATS C-Test should check a case like that given in the !Issue, and a

similar case for the Caller attribute.

!appendix

This issue was created from private mail from Steve Baird; the solution was

suggested by Tucker Taft.

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