Version 1.4 of ai12s/ai12-0089-1.txt

Unformatted version of ai12s/ai12-0089-1.txt version 1.4
Other versions for file ai12s/ai12-0089-1.txt

!standard 3.10.2(7/3)          14-05-08 AI05-0089-1/03
!standard 3.10.2(19.2/3)
!standard 3.10.2(19.3/3)
!standard 6.5(4/3)
!class binding interpretation 13-10-31
!status Corrigendum 2014 13-12-18
!status WG9 Approved 14-06-27
!status ARG Approved 10-0-1 13-11-16
!status work item 13-10-31
!status received 13-10-07
!priority Low
!difficulty Easy
!qualifier Omission
!subject Accessibility rules need to take into account that a generic function is not a function
!summary
The accessibility rules for explicitly aliased parameters and access results also apply in generic function bodies.
!question
Repeat after me: a generic function is not a function. :-)
However, the special accessibility rules for aliased parameters of functions do not take this into account, and thus do not apply inside of a generic function.
Thus, an example like:
type Return_It (D : access Element) is null record;
generic function Foobar (X : aliased in out Bounded_Container; C : in Cursor) return Return_It;
function Foobar (X : aliased in out Bounded_Container; C : in Cursor) return Return_It is begin ... return R : Return_It (X(C)'access); -- What accessibility check here? end Foobar;
would seem to fail a compile-time accessibility in the return statement, whereas the non-generic equivalent would always be legal.
This is weird, should be it be changed? (Yes.)
!recommendation
(See Summary.)
!wording
[Editor: It's appropriate that I'm writing this on Halloween, because every trip to the Heart of Darkness is scary!! :-0]
Modify 3.10.2(7/3) as modified by AI12-0067-1:
... Other than for an explicitly aliased parameter of a function {or generic function}, a formal parameter of a callable entity has the same accessibility level as the master representing the invocation of the entity.
Modify 3.10.2(19.2/3):
Inside a return statement that applies to a function {or generic function} F, when determining whether the accessibility level of an explicitly aliased parameter of F is statically deeper ...
Modify 3.10.2(19.3/3):
For determining whether a level is statically deeper than the level of the anonymous access type of an access result of a function {or generic function F}, when within a return statement that applies to [the function]{F}, the level of the master of the call is presumed to be the same as that of the level of the master that elaborated the [function] body{ of F}.
Add after 6.5(4/2):
AARM To Be Honest: The above also applies to generic subprograms, even though they are not callable constructs. (An instance of a generic subprogram is a callable construct, but not a generic subprogram itself.)
Add after AARM 6.5(5.b/2):
AARM Ramification: Since a "function body" includes a generic function body, this rule and all of the following Legality Rules apply to generic function bodies as well as non-generic function bodies. This is true even though a generic function is not a function.
!discussion
Repeat after me: a generic function is not a function, a generic procedure is not a procedure, and a generic package is not a package. Even long-time Ada experts tend to forget this, and we clearly did when we fixed the rules in AI12-0067-1, not to mention when we created the rules in the first place.
This falls under the Dewar rule that the Standard does not say nonsense even when it literally does say nonsense. No one would expect a function and a similar generic function to have different accessibility rules for aliased parameters.
We have to change the rule for access results of a function, as it has the same problem.
Note that we don't have to change any dynamic semantics rules, as those can only occur in an instance of a generic function, which IS a function. [A generic unit is not executable, only an instance is.] This means that we don't need to modify 3.10.2(13.3/3), for example.
There is a similar problem in the Legality Rules of 6.5. However, that is mitigated somewhat as a generic function body is considered a function body, and most of the rules are about function bodies rather than functions per-se. Thus we just add a pair of AARM notes.
!corrigendum 3.10.2(7/3)
Replace the paragraph:
by:
!corrigendum 3.10.2(19.2/3)
Replace the paragraph:
by:
!corrigendum 3.10.2(19.3/3)
Replace the paragraph:
by:
!ASIS
No changes needed.
!ACATS test
An ACATS C-Test is needed to check that the example in the question is legal.
!appendix

From: Randy Brukardt
Sent: Monday, October 7, 2013  8:09 PM

John asked in his editorial review of AI12-0067-1:

>I am not sure that I like the term non-function in the !subject. Are
>generic functions functions or not? We could say procedures and entries.

Of course :-), generic functions are not functions. (Let's not discuss yet
again how silly that is, that's not a productive use of time.)

That makes me wonder if we have the right definition for the accessibility
rules for explicitly aliased parameters. The rules apply only to functions
(presumably including instances of generic functions), but do not appear
to apply to generic function bodies. Thus, an example like:

     type Return_It (D : access Element) is null record;

     generic
     function Foobar (X : aliased in out Bounded_Container; C : in Cursor) return Return_It;

     function Foobar (X : aliased in out Bounded_Container; C : in Cursor) return Return_It is
     begin
         ...
         return R : Return_It (X(C)'access); -- What accessibility check here?
     end Foobar;

would seem to fail a compile-time accessibility in the return statement,
whereas the non-generic equivalent would always be legal.

This is a pretty unlikely case (most such functions will be in a package of
some sort, which would eliminate the problem).

It seems to me that 3.10.2(7/3) needs to say "of a function or generic
function" (rather than just "of a function" as added by AI12-0067-1), and
that 3.10.2(13.3/3) needs to say "The accessibility level of an explicitly
aliased (see 6.1) formal parameter in a function {or generic function} body
is determined by the point of call; it is the same level that the return
object ultimately will have.".

(I didn't check if there was any other wording that will need to be changed
similarly, I first wanted to check if this is right so far.)

So:
(1) Am I right that there is a (minor) problem here?
(2) Should we reopen AI12-0067-1 to make this fix, or make a new AI just for
this case?

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

Questions? Ask the ACAA Technical Agent