AI22-0043-1
!standard 3.9.2(17/2) 22-11-17 AI22-0043-1/03
!standard 3.9.2(18/2)
!standard 3.9.2(18.1/2)
!standard 3.9.2(19)
!class Binding Interpretation 22-06-15
!status Corrigendum 1-2022 22-09-09
!status ARG Approved 8-0-2 22-09-09
!status work item 22-06-15
!status received 22-06-09
!priority Medium
!difficulty Medium
!qualifier Omission
!subject Tags from context for tag-indeterminate calls
The wording in 3.9.2(18) and in 3.9.2(18.1) talks about parenthesized expressions and qualified expressions, but fails to mention other similar cases (e.g., conditional expressions, declare
expressions). This was an oversight.
For purposes of determining whether a tag-indeterminate call takes its tag from its enclosing context, should an enclosing conditional expression or an enclosing declare expression be treated similarly to an enclosing qualified expression or an enclosing parenthesized expression? (Yes.)
In this example,
package Pkg; |
should the controlling tag in the first call to Pkg.F be determined by the other parameter in the enclosing call to Pkg.Op? (Yes.) What about the controlling tag in the second call to Pkg.F? (No.)
Treat conditional expressions and declare expressions similarly to qualified expressions and parenthesized expressions in determining the tag of a tag-indeterminate call. Ada already defines the term “operative constituent”. That term should be used in resolving this issue in order to avoid repetition.
!wording
Replace 3.9.2(17/2 - 19) with:
[Editor’s note: The first and last paragraphs here are unchanged, only the middle three are different.]
No change is intended for the case of a tag-indeterminate call that occurs as the operand of a view conversion. If the term “operative constituent” is to be used in any new wording, then care is needed to accomplish this goal because a view conversion is treated like a qualified expression or a parenthesized expression in the definition of that term.
The use of “tag-indeterminate controlling operand” in the wording as opposed to just “controlling operand” is important because of the case of a tag-indeterminate call that is the operand of a view conversion. Similarly for the use of “tag-indeterminate expression” as opposed to just “expression”. Thanks to Tuck for suggesting this.
(See Issue.)
@drepl
@xinbull{If the call has a controlling result or controlling access result and is itself, or designates, a (possibly parenthesized or qualified) controlling operand of an enclosing call on a dispatching operation of a descendant of type T, then its controlling tag value is determined by the controlling tag value of this enclosing call;}
@dby
@xinbull{If the call has a controlling result or controlling access result that is itself, or designates, the evaluated operative constituent (see 4.4) of:}
@xin2bull{a tag-indeterminate controlling operand of an enclosing call on a dispatching operation of a descendant of type @i{T}, then the controlling tag value is determined by the controlling tag value of this enclosing call;}
@xin2bull{a tag-indeterminate expression of an @fa{assignment_statement} whose target is of a class-wide type, then the controlling tag value is determined by the target;}
@ddel
@xinbull{a tag-indeterminate expression of an @fa{assignment_statement} whose target is of a class-wide type, then the controlling tag value is determined by the target;}
An executable test could be written to confirm that the desired new program behavior is implemented for tag-indeterminate calls within conditional expressions and within declare expressions, and that program behavior is unchanged for tag-indeterminate calls within view conversions.