!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)

@drepl
@xbullet<An entity or view defined by a declaration and created as part of
its elaboration has the same accessibility
level as the innermost master of the declaration
except in the cases of renaming and derived access types described below.
Other than for an explicitly aliased parameter, a formal parameter of a
callable entity has the same accessibility level as the master representing
the invocation of the entity.>
@dby
@xbullet<An entity or view defined by a declaration and created as part of
its elaboration has the same accessibility
level as the innermost master of the declaration
except in the cases of renaming and derived access types described below.
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.>

!corrigendum 3.10.2(19.2/3)

@drepl
@xbullet<Inside a return statement that applies to a function @i<F>, when
determining whether the accessibility level of an explicitly
aliased parameter of @i<F> is statically deeper than the level of the
return object of @i<F>, the level of the return object is considered to
be the same as that of the level of the explicitly aliased
parameter; for statically comparing with the level of other
entities, an explicitly aliased parameter of @i<F> is considered to have
the accessibility level of the body of @i<F>.>
@dby
@xbullet<Inside a return statement that applies to a function or
generic function @i<F>, when
determining whether the accessibility level of an explicitly
aliased parameter of @i<F> is statically deeper than the level of the
return object of @i<F>, the level of the return object is considered to
be the same as that of the level of the explicitly aliased
parameter; for statically comparing with the level of other
entities, an explicitly aliased parameter of @i<F> is considered to have
the accessibility level of the body of @i<F>.>

!corrigendum 3.10.2(19.3/3)

@drepl
@xbullet<For determining whether a level is statically deeper than the
level of the anonymous access type of an access result of a function,
when within a return statement that applies to the function, 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.>
@dby
@xbullet<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 @i<F>, when within a return statement that applies
to @i<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 body of @i<F>.>

!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?

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