AI22-0015-1

!standard 3.9(26.1/3)          23-09-07 AI22-0015-1/02

!standard 3.10.2(14/3)

!standard 7.6.1(11.3/3)

!standard 7.6.1(11.4/3)

!class binding interpretation 21-11-12

!status Amendment 1-2022 23-06-26

!status WG9 Approved 23-10-12

!status ARG Approved 7-0-1 23-06-11

!status work item 21-11-12

!status received 21-04-28

!submitter Tucker Taft (for an unnamed AdaCore engineer)

!priority Low

!difficulty Easy

!qualifier Clarification

!subject Innermost master of the call is ambiguous

!summary

Ambiguous wording is clarified.

!issue

The phrase "innermost master of the call" as used in 3.10.2(14/3) is somewhat ambiguous, as it could mean "master of the function call" which has its own definition, or "innermost master that evaluated the call" which depends on the general definition of "master". Should we replace any such ambiguous phrases with a more explicit phrase? (Yes.)

!recommendation

Here are the potentially ambiguous uses we have identified:

3.9(26.1/3): Internal_Tag should return the tag of a type, if one exists, whose innermost master is a master of the point of the function call.

3.10.2(14/3): ... For an anonymous allocator defining the value of an access parameter, the accessibility level is that of the innermost master of the call. ...

7.6.1(11.3/3): For the type of an access parameter, the call that contains the allocator.

7.6.1(11.4/3): For the type of an access result, within the master of the call (see 3.10.2).

We propose that each of these be reworded to be explicit about whether we are talking about the master that evaluated the function call, or the "master of the function call" as defined in 3.10.2.

!wording

Modify 3.9(26.1/3):

Internal_Tag should return the tag of a type, if one exists, whose innermost master is a master of the point of {evaluation of} the function call.

Modify 3.10.2(14/3):

... For an anonymous allocator defining the value of an access parameter, the accessibility level is that of the innermost master of {the evaluation of} the call. ...

Modify 7.6.1(11.3/3):

For the type of an access parameter, {the evaluation of} the call that contains the allocator.

Modify 7.6.1(11.4/3):

For the type of an access result, within the master of the {function} call (see 3.10.2).

!discussion

We have added "the evaluation of" in three of the ambiguous places, and added "function" in the one place that is intended to be a reference to the phrase "master of the function call".

One could argue that in cases where the master of the function call is not the same as the innermost master that evaluated the call, this should have an effect on what is the master for an anonymous allocator of an access parameter, to be more consistent with the rules for aliased parameters. But anonymous allocators are generally frowned upon in various circles, so suggesting such a change would probably not be popular. Efforts to move away from run-time accessibility checks argue for replacing access parameters with aliased parameters, so such allocators would hopefully become even less common.

!corrigendum 3.9(26.1/3)

@drepl
Internal_Tag should return the tag of a type, if one exists, whose innermost
master is a master of the point of the function call.
@dby
Internal_Tag should return the tag of a type, if one exists, whose innermost
master is a master of the point of evaluation of the function call.

!corrigendum 3.10.2(14/3)

@drepl
@xbullet{The accessibility level of an object created by an @fa{allocator} is the
same as that of the access type, except for an @fa{allocator} of an anonymous
access type (an @i{anonymous allocator}) in certain contexts, as follows: For an
anonymous allocator that defines the result of a function with an access result,
the accessibility level is determined as though the @fa{allocator} were in place
of the call of the function; in the special case of a call that is the operand of
a type conversion, the level is that of the target access type of the conversion.
For an anonymous allocator defining the value of an access parameter, the
accessibility level is that of the innermost master of the call. For an anonymous
allocator whose type is that of a stand-alone object of an anonymous
access-to-object type, the accessibility level is that of the declaration of the
stand-alone object. For one defining an access discriminant, the accessibility level
is determined as follows:}
@dby
@xbullet{The accessibility level of an object created by an @fa{allocator} is the
same as that of the access type, except for an @fa{allocator} of an anonymous
access type (an @i{anonymous allocator}) in certain contexts, as follows: For an
anonymous allocator that defines the result of a function with an access result,
the accessibility level is determined as though the @fa{allocator} were in place
of the call of the function; in the special case of a call that is the operand of
a type conversion, the level is that of the target access type of the conversion.
For an anonymous allocator defining the value of an access parameter, the
accessibility level is that of the innermost master of the evaluation of the call.
For an anonymous allocator whose type is that of a stand-alone object of an anonymous
access-to-object type, the accessibility level is that of the declaration of the
stand-alone object. For one defining an access discriminant, the accessibility level
is determined as follows:}

!corrigendum 7.6.1(11.3/3)

@drepl
@xbullet{For the type of an access parameter, the call that
contains the @fa{allocator}.}
@dby
@xbullet{For the type of an access parameter, the evaluation of the call that
contains the @fa{allocator}.}

!corrigendum 7.6.1(11.4/3)

@drepl
@xbullet{For the type of an access result, within the master of the
call (see 3.10.2).}
@dby
@xbullet{For the type of an access result, within the master of the function
call (see 3.10.2).}

!ACATS test

No ACATS tests should be needed, as this is only clarifying existing wording, no change is intended.

!appendix

From: Tucker Taft

Sent: Friday, June 25, 2021 6:25 AM

An AdaCore engineer bumped into a confusing phrase in 3.10.2(14/3) where we

use "innermost master of the call" as a shorthand for "innermost master that

evaluated the call." This shorthand predates the definition of the term

"master of the function call" but can now be seen as potentially confusing.

It could be interpreted as "innermost master of the function call" which

might be interpreted as essentially the same as "master of the function call."

So I would suggest we expand any uses of the shorthand "master of the call" to

either "master of the function call" or "master that evaluated the call" as

appropriate to the context, to avoid any such confusion.

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

From: Tullio Vardanega

Sent: Friday, June 25, 2021 7:41 AM

Seems useful and opportune to me.

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