# CVS difference for ai05s/ai05-0235-1.txt

Differences between 1.4 and version 1.5
Log of other versions for file ai05s/ai05-0235-1.txt

```--- ai05s/ai05-0235-1.txt	2011/02/15 03:08:44	1.4
+++ ai05s/ai05-0235-1.txt	2011/02/15 05:59:56	1.5
@@ -1,19 +1,24 @@
-!standard  3.10.2(7/2)                             11-02-14    AI05-0235-1/02
+!standard  3.10.2(7/2)                             11-02-14    AI05-0235-1/03
+!standard  3.10.2(19.2/3)
!reference AI05-0142-4
!class Amendment 10-11-18
!status work item 10-11-18
!priority Low
!difficulty Easy
-!subject Contradiction in accessibility of explicitly aliased parameters
+!subject Accessibility of explicitly aliased parameters
!summary

-The contradiction is resolved by added "unless otherwise specified" to
+(1) The contradiction is resolved by added "unless otherwise specified" to
3.10.2(7/2).

+(2) Explicitly aliased parameters have special accessibility only within the
+return statement of a function; otherwise, they have the same accessibility
+as "normal" parameters.
+
!question

-The last sentence of 3.10.2(7/2) says "A parameter of a master has the same
+(1) The last sentence of 3.10.2(7/2) says "A parameter of a master has the same
accessibility level as the master." Besides being vague, this conflicts with
the 3.10.2(13.3/3) added by AI05-0142-4: "The accessibility level of an
explicitly aliased (see 6.1) formal parameter in a function body is determined
@@ -23,24 +28,42 @@
The level surely cannot be both at the same time. Which is intended? (The
second.)

+(2) Consider:
+
+    type A_T is access all T;
+    P : A_T;
+
+    function F (L : aliased T) return Natural is
+    begin
+        P := L'access; -- Static check succeeds.
+          ...
+    end F;
+
+Based on the wording of 3.10.2(19.2/3), it appears that the static check
+succeeds here, as L is considered to have the "master that elaborated
+the function body of F", and that is the same master that elaborated A_T.
+
+Is this right? (No.)
+
!wording

Modify the last sentence of 3.10.2(7/2) and add the following AARM notes:

{Unless otherwise specified in this International Standard, a}[A]
{formal} parameter of [a master] {a callable entity} has the same
-  accessibility level as the master {representing the invocation of the
-  entity}.
+  accessibility level as the master {that is the execution of the
+  called entity}.

-  [Editor's note: Changing to "invocation of the entity" from
-  "(parameter of) a master" has the nasty side-effect of undefining the
-  static accessibility level (since an "invocation" cannot be considered
-  statically). That's why I tried to use "master of the entity", but it
-  clearly doesn't make much sense either.]
+AARM To Be Honest: We use "that is the execution of" as that is the definition
+of a master. But we mean this to be interpreted statically (for instance, as
+the body of the subprogram) for the purposes of computing "statically deeper
+than" (see below).

AARM Ramification: Note that accessibility can differ depending on the view of
-an object (for both static and dynamic accessibility). This can occur in a
-number of cases, not just the formal parameter case mentioned here.
+an object (for both static and dynamic accessibility). For instance, the
+accessibility level of a formal parameter may be different than the
+accessibility level of the corresponding actual parameter. This can occur in
+other cases as well.

AARM Reason: We define the (dynamic) accessibility of formal parameters in
order that it does not depend on the parameter passing model (by-reference or
@@ -49,12 +72,29 @@

End AARM Notes.

+Replace 3.10.2(19.2/3) by
+
+Inside a return statement that applies to a function F, when determining
+whether the accessibility level of an explicitly aliased parameter of F is
+statically deeper than the level of the return object of 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 F is considered to have
+the accessibility level of the body of F.
+
!discussion

-The wording of 3.10.2(7/2) is quite vague. It is clear that it doesn't make
+(1) The wording of 3.10.2(7/2) is quite vague. It is clear that it doesn't make
sense for this rule to apply to actual parameters, so it is only talking about
formal parameters of a callable entity.

+(2) Allowing cases like this would require the dynamic check to catch problems,
+and that would imply some overhead (once per function call, not per parameter)
+to pass an accessibility level. That's necessary because we need to detect
+local calls where local objects might have been passed.
+
+That overhead doesn't seem to buy us anything, so we change the wording to
+eliminate it (other than in the cases covered by AI05-0234-1).

!ACATS Test

@@ -439,3 +479,676 @@

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

+From: Randy Brukardt
+Sent: Thursday, November 18, 2010  8:48 PM
+
+I had an action item to look for problems involving explicitly aliased
+parameters with these examples.
+
+First of all, for procedures, there is no special accessibility for these
+parameters (nor special checks on calls). So I'll only consider function calls.
+
+The accessibility rule for functions is: (3.10.2(13.3/3))
+
+The accessibility level of an explicitly aliased (see 6.1) formal parameter in a
+function body is determined by the point of call (which is the same level that
+the return object ultimately will have).
+
+There is also a static rule, but since this is a purely dynamic check, it is
+irrelevant.
+
+Next, for return statements, an explicitly aliased parameter will always pass
+the accessibility check. (That's the whole point of this definition, the checks
+at the call site, etc.) That clearly includes this new check, so there is
+nothing further to think about there. That even includes an allocator for an
+anonymous access return type.
+
+So the question boils down to whether there can be a problem with an allocator.
+That would look something like:
+
+       function F (L : aliased T) return Natural is
+       begin
+           P := new T'Class(L);
+           ...
+       end F;
+
+(This is not the intended usage of such parameters, but since it is possible, we
+have to consider it.)
+
+Whether the check would succeed or fail would depend upon where the type of P
+was declared. If P is local, the check would always succeed. If P's type is
+declared outside of F, whether the check would succeed might depend on where the
+call originated. For instance, if P is library-level, then a library-level call
+to F could succeed, while a nested call would fail. This would seem to have a
+small amount of overhead, but it is once per function (not per parameter), and
+is only needed in functions with aliased parameters. So that doesn't seem to be
+a major problem (although it is annoying).
+
+This is the case that the static check was intended to avoid, although it is not
+clear to me that it succeeds anyway. (If the function was elaborated at library
+level, one would expect the above to pass the static check given 3.10.2(19.3/3),
+and then the dynamic check would still be needed.)
+
+So, for now I don't see any need to change anything here.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, November 18, 2010  8:58 PM
+
+>         function F (L : aliased T) return Natural is
+>         begin
+>             P := new T'Class(L);
+>             ...
+>         end F;
+>
+> (This is not the intended usage of such parameters, but since it is
+> possible, we have to consider it.)
+>
+> Whether the check would succeed or fail would depend upon where the
+> type of P was declared. If P is local, the check would always succeed.
+> If P's type is declared outside of F, whether the check would succeed
+> might depend on where the call originated...
+
+I don't think this is worth the trouble.  I suggest we treat these exactly like
+local variables except when checking the accessibility on a return statement.
+
+> So, for now I don't see any need to change anything here.
+
+Seems to me we want it to fail if P's type is non-local, and L has any access
+discriminants.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, November 18, 2010  9:24 PM
+
+I agree in this case, but the issue is that this is exactly what is required in
+the normal case:
+
+    type A_T is access all T;
+    P : A_T;
+
+    function F (L : aliased T) return Natural is
+    begin
+        P := L'access; -- Static check succeeds.
+          ...
+    end F;
+
+So there is no extra overhead here for the access discriminant check; it already
+exists.
+
+The more interesting question is whether we intended that or we just screwed up
+the rules.
+
+My recollection (and the start of this entire thread) was that we had intended
+the static check to prevent such cases, so that no dynamic check would ever be
+needed. But it clearly doesn't (A_T and F are elaborated by the same master, so
+the static accessibility has to pass, but if the call to F is from a nested
+scope, a local object could be passed to the parameter, so the dynamic check
+would fail).
+
+I think we were trying to represent the half level between the function and it's
+declaration (that is, the parameter should be less local than a local object,
+but more local than anything declared where the function is), but we screwed up
+the wording.
+
+One possible fix for the normal case would be to give up on the special static
+accessibility outside of return statements. We've already done that partway, and
+we could just forget the whole thing. But it would be better to get it right and
+accurately reflect the half-level.
+
+But that doesn't help for the access discriminant check, because there is no
+static accessibility to help us. And I would be really against the *dynamic*
+accessibility depending on where an entity is used -- I don't have a clear idea
+of how that could reasonably be implemented. Only global variables come to mind,
+and that is awful. I can't think of any case currently where we would generate
+different code deep in an expression tree depending on context (it sometimes
+happens at the top-level for optimization, but I don't think it ever happens
+inside of a tree).
+
+What a tangled web of accessibility we weave...
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, November 18, 2010  9:55 PM
+
+...
+> So there is no extra overhead here for the access discriminant check;
+> it already exists.
+
+Sorry, I am confused.  You say the static check succeeds above.  I would have
+said it failed.  As far as the access discriminant check, the interesting case
+is when the aliased parameter is of a class-wide type, and we don't know until
+run-time whether there is an access discriminant.
+
+    So the case of interest is:
+      function F (L : aliased T'Class) return Natural is
+      begin
+           P := new T'Class(L);
+           return 2;
+      end F;
+
+I would say this should fail if L has any access discriminants, independent of
+the actual parameter's accessibility. We aren't passing an accessibility level
+along with "aliased" parameters, so I don't see how we could know the "true"
+accessibility level of the actual parameter anyway.  The point of aliased
+parameters is that a reference to some part of the parameter can be returned
+from the function.  In other contexts, they behave just like "regular"
+parameters (except that they are aliased, of course).
+
+I don't really follow the rest of this argument...
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, November 18, 2010  10:33 PM
+
+> Sorry, I am confused.  You say the static check succeeds above.  I
+> would have said it failed.
+
+Why do you say that? Maybe it *should* have failed, but that doesn't appear to
+be the case.
+
+For the static check, 3.10.2(19.3/3) says in part:
+
+...for statically comparing with the level of other entities, the level of the
+return object of F is considered to be the same as that of the master that
+elaborated the function body of F.
+
+The master that elaborated A_T and the master that elaborated F are the same, so
+I can't see any reason for the static check to have failed in this example.
+
+Are you saying this wording is not what we intended? That's surely possible; I
+was trying to figure out the consequences assuming that it was correct, but
+perhaps that was a waste of time.
+
+(I note this wording seems to have lost the fact that it is defining the level
+of the return object for the purpose of defining the level of explicitly aliased
+parameters; this follows from the fact that explicitly aliased parameters are
+always defined to have the level of the return object by 3.10.2(13.3/3), but it
+surely is convoluted. Since we're talking about when we're not in a return
+statement, we can't have any access to the return object.)
+
+> As far as the access
+> discriminant check, the interesting case is when the aliased parameter
+> is of a class-wide type, and we don't know until run-time whether
+> there is an access discriminant.
+>
+>     So the case of interest is:
+>       function F (L : aliased T'Class) return Natural is
+>       begin
+>            P := new T'Class(L);
+>            return 2;
+>       end F;
+>
+> I would say this should fail if L has any access discriminants,
+> independent of the actual parameter's accessibility.
+> We aren't passing an accessibility level along with "aliased"
+> parameters, so I don't see how we could know the "true"
+> accessibility level of the actual parameter anyway.  The point of
+> aliased parameters is that a reference to some part of the parameter
+> can be returned from the function.  In other contexts, they behave
+> just like "regular" parameters (except that they are aliased, of
+> course).
+
+OK, but how in heaven's name do you propose to accomplish this? This is a
+*dynamic* check, so the static accessibility is irrelevant. I suppose you could
+try to craft a legality rule specifically for this case, but that is going to
+make a lot legitimate code illegal. The alternative is to say that the dynamic
+accessibility of an explicitly aliased parameter depends on where it is used --
+an idea that I'm strongly opposed to (I have no idea how to code generate that
+-- remember that the uses could be deeply nested in very complex expressions --
+how would you do it??).
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, February 14, 2011  1:55 PM
+
+     I think this is the e-mail related to AI-234 that you indicated was still
+     awaiting a response.  So here is my response.
+
+...
+> Why do you say that? Maybe it *should* have failed, but that doesn't
+> appear to be the case.
+>
+> For the static check, 3.10.2(19.3/3) says in part:
+>
+> ...for statically comparing with the level of other entities, the
+> level of the return object of F is considered to be the same as that
+> of the master that elaborated the function body of F.
+
+I think you are cheating a bit here, since the first part of this sentence
+specifically addresses what happens when you compare the accessibility level of
+a return object with an aliased param.  Perhaps this paragraph should go on to
+say that when statically comparing the level of an aliased parameter with
+anything but the return object of F, the aliased parameter is treated like a
+local variable. That might obviate any separate rule for the accessibility level
+of an aliased parameter.
+
+>
+> The master that elaborated A_T and the master that elaborated F are
+> the same, so I can't see any reason for the static check to have
+> failed in this example.
+>
+> Are you saying this wording is not what we intended? That's surely
+> possible; I was trying to figure out the consequences assuming that it
+> was correct, but perhaps that was a waste of time.
+>
+> (I note this wording seems to have lost the fact that it is defining
+> the level of the return object for the purpose of defining the level
+> of explicitly aliased parameters; this follows from the fact that
+> explicitly aliased parameters are always defined to have the level of
+> the return object by 3.10.2(13.3/3), but it surely is convoluted.
+> Since we're talking about when we're not in a return statement, we
+> can't have any access to the return
+> object.)
+
+OK, I see your logic, and that convinces me that we should either make the
+change I suggested above, or change 13.3/3 to say something like:
+
+    Within a return statement that applies to a function body, the
+    accessibility level of an explicitly aliased (see 6.1) formal
+    parameter of the function is determined by the point of call;
+    it is the same level that the return object ultimately will have.
+    Outside of a return statement that applies to the function body,
+    the formal parameter has the same accessibility level as that
+    of any other formal parameter[Redundant:, namely that of the master
+    representing the invocation of the function body].
+
+I think I somewhat prefer making the change to the rules associated with
+statically comparing aliased parameters, and eliminate the separate standalone
+rule in 13.3/3 for the accessibility level of an aliased parameter. Then they
+would follow the normal rule for formal parameters, namely they are treated like
+local variables, except when being statically compared against the level of the
+return object.
+
+>> As far as the access
+>> discriminant check, the interesting case is when the aliased
+>> parameter is of a class-wide type, and we don't know until run-time
+>> whether there is an access discriminant.
+>>
+>>      So the case of interest is:
+>>        function F (L : aliased T'Class) return Natural is
+>>        begin
+>>             P := new T'Class(L);
+>>             return 2;
+>>        end F;
+>>
+>> I would say this should fail if L has any access discriminants,
+>> independent of the actual parameter's accessibility.
+>> We aren't passing an accessibility level along with "aliased"
+>> parameters, so I don't see how we could know the "true"
+>> accessibility level of the actual parameter anyway.  The point of
+>> aliased parameters is that a reference to some part of the parameter
+>> can be returned from the function.  In other contexts, they behave
+>> just like "regular" parameters (except that they are aliased, of
+>> course).
+>
+> OK, but how in heaven's name do you propose to accomplish this? This
+> is a
+> *dynamic* check, so the static accessibility is irrelevant. I suppose
+> you could try to craft a legality rule specifically for this case, but
+> that is going to make a lot legitimate code illegal. The alternative
+> is to say that the dynamic accessibility of an explicitly aliased
+> parameter depends on where it is used -- an idea that I'm strongly
+> opposed to (I have no idea how to code generate that -- remember that
+> the uses could be deeply nested in very complex expressions -- how would you do it??).
+
+I believe 4.8(10.1) already addresses this case, and the fact that L is an
+aliased parameter should make no difference.  Now if the allocator were inside
+the return statement for F, then the fact that L is aliased could make a
+difference, in that the objects designated by its access discriminants must live
+at least as long as the return object, but that still isn't very long.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, February 14, 2011  7:52 PM
+
+> I think you are cheating a bit here, since the first part of this
+> sentence specifically addresses what happens when you compare the
+> accessibility level of a return object with an aliased param.  Perhaps
+> this paragraph should go on to say that when statically comparing the
+> level of an aliased parameter with anything but the return object of
+> F, the aliased parameter is treated like a local variable.
+> That might obviate any separate rule for the accessibility level of an
+> aliased parameter.
+
+I'm not cheating per-se; the original intent of the static check was to
+represent the "half-level" model for return objects and aliased parameters. This
+was an attempt to word that model.
+
+Probably the problem here is that the "half-level" model really doesn't have any
+useful effect for parameters outside of return statements. About the only case
+where it might be meaningful would be an assignment from one aliased parameter
+to an anonymous component of another - no, even that doesn't work.
+
+So probably we should just replace 3.10.2(19.2/3) with something like:
+
+Inside a return statement that applies to a function F, when determining whether
+the accessibility level of an explicitly aliased parameter of F is statically
+deeper than the level of the return object of 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, the level
+of an explicitly aliased parameters of F is considered to be the same as that of
+a local object of F.
+
+Aside about AI05-0235-1: It appears that the old wording for parameters was
+intended to have a double meaning -- it seems to mean something different for
+static and dynamic accessibility. Since we rewrote the paragraph to make sense
+for dynamic accessibility, it no longer works for static accessibility (the
+levels aren't statically nested, so we can't apply 3.10.2(18)). I wonder if we
+need a more general bullet for parameters:
+
+* Unless otherwise specified, the accessibility level of a formal parameter of a
+  callable entity is considered to be the same as that of a local object of F.
+
+Perhaps we should put this entire discussion into AI05-0235-1 -- except that
+Steve wants to use his handy-dandy "ultimate accessibility levels" in
+3.10.2(13.3/3).
+End aside.
+
+...
+> OK, I see your logic, and that convinces me that we should either make
+> the change I suggested above, or change 13.3/3 to say something like:
+>
+>     Within a return statement that applies to a function body, the
+>     accessibility level of an explicitly aliased (see 6.1) formal
+>     parameter of the function is determined by the point of call;
+>     it is the same level that the return object ultimately will have.
+>     Outside of a return statement that applies to the function body,
+>     the formal parameter has the same accessibility level as that
+>     of any other formal parameter[Redundant:, namely that of the master
+>     representing the invocation of the function body].
+
+I don't think we want to mess with the dynamic accessibility rules. I strongly
+object to having a context-dependent dynamic accessiblity check: I don't think
+there are any cases currently -- the value is always determined by the entity
+being checked. It sounds like a pain to implement context-specific checks (given
+these can be nested in many levels of calls and allocators).
+
+...
+> >> As far as the access
+> >> discriminant check, the interesting case is when the aliased
+> >> parameter is of a class-wide type, and we don't know until run-time
+> >> whether there is an access discriminant.
+> >>
+> >>      So the case of interest is:
+> >>        function F (L : aliased T'Class) return Natural is
+> >>        begin
+> >>             P := new T'Class(L);
+> >>             return 2;
+> >>        end F;
+> >>
+> >> I would say this should fail if L has any access discriminants,
+> >> independent of the actual parameter's accessibility.
+> >> We aren't passing an accessibility level along with "aliased"
+> >> parameters, so I don't see how we could know the "true"
+> >> accessibility level of the actual parameter anyway.  The point of
+> >> aliased parameters is that a reference to some part of the
+> >> parameter can be returned from the function.  In other contexts,
+> >> they behave just like "regular" parameters (except that they are
+> >> aliased, of course).
+> >
+> > OK, but how in heaven's name do you propose to accomplish this? This
+> > is a
+> > *dynamic* check, so the static accessibility is irrelevant. I
+> > suppose you could try to craft a legality rule specifically for this
+> > case, but that is going to make a lot legitimate code illegal. The
+> > alternative is to say that the dynamic accessibility of an
+> > explicitly aliased parameter depends on where it is used -- an idea
+> > that I'm strongly opposed to (I have no idea how to code generate
+> > that -- remember that the uses could be deeply nested in very
+> > complex expressions
+> -- how would you do it??).
+>
+> I believe 4.8(10.1) already addresses this case, and the fact that L
+> is an aliased parameter should make no difference.
+> Now if the allocator were inside the return statement for F, then the
+> fact that L is aliased could make a difference, in that the objects
+> designated by its access discriminants must live at least as long as
+> the return object, but that still isn't very long.
+
+I think Steve is trying to address this case, so my question is OBE. So I
+recommend leaving 3.10.2(13.3/3) [modulo changing it to use Steve's "ultimate
+accessibility level" rather than "the level that the return object will
+ultimately have", which is the same thing, but the former is worded more
+formally].
+
+Note that the dynamic check is definitely needed in these cases (the AI05-0234-1
+cases), so removing that definition is not going to work.
+
+Probably this case gets left in AI05-0234-1, and we'll let Steve get it exactly
+right.
+
+The static case probably should get dumped into AI05-0235-1, since it is at
+least as closely related to that.
+
+Thoughts??
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, February 14, 2011  8:15 PM
+
+> So probably we should just replace 3.10.2(19.2/3) with something like:
+>
+> Inside a return statement that applies to a function F, when
+> determining whether the accessibility level of an explicitly aliased
+> parameter of F is statically deeper than the level of the return
+> object of 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, the level of an
+> explicitly aliased parameters of F is considered to be the same as that of a local object of F.
+
+That sounds about right.
+
+> Aside about AI05-0235-1: It appears that the old wording for
+> parameters was intended to have a double meaning -- it seems to mean
+> something different for static and dynamic accessibility. Since we
+> rewrote the paragraph to make sense for dynamic accessibility, it no
+> longer works for static accessibility (the levels aren't statically
+> nested, so we can't apply 3.10.2(18)). I wonder if we need a more general bullet for parameters:
+>
+> * Unless otherwise specified, the accessibility level of a formal
+> parameter of a callable entity is considered to be the same as that of
+> a local object of F.
+
+I'm not sure why we need the "unless otherwise specified" any more.
+
+> Perhaps we should put this entire discussion into AI05-0235-1 --
+> except that Steve wants to use his handy-dandy "ultimate accessibility
+> levels" in 3.10.2(13.3/3).
+> End aside.
+>
+> ...
+>> OK, I see your logic, and that convinces me that we should either
+>> make the change I suggested above, or change 13.3/3 to say something
+>> like:
+>>
+>>      Within a return statement that applies to a function body, the
+>>      accessibility level of an explicitly aliased (see 6.1) formal
+>>      parameter of the function is determined by the point of call;
+>>      it is the same level that the return object ultimately will have.
+>>      Outside of a return statement that applies to the function body,
+>>      the formal parameter has the same accessibility level as that
+>>      of any other formal parameter[Redundant:, namely that of the master
+>>      representing the invocation of the function body].
+>
+> I don't think we want to mess with the dynamic accessibility rules. I
+> strongly object to having a context-dependent dynamic accessiblity
+> check: I don't think there are any cases currently -- the value is
+> always determined by the entity being checked. It sounds like a pain
+> to implement context-specific checks (given these can be nested in
+> many levels of calls and allocators).
+
+I *think* we are agreeing here, namely we should get rid of 13.3/3, and make the
+change you suggested above to 19.2/3.
+
+> I think Steve is trying to address this case, so my question is OBE.
+> So I recommend leaving 3.10.2(13.3/3) [modulo changing it to use
+> Steve's "ultimate accessibility level" rather than "the level that the
+> return object will ultimately have", which is the same thing, but the
+> former is worded more formally].
+
+Why do we need paragraph 13.3/3 any more?
+
+> Note that the dynamic check is definitely needed in these cases (the
+> AI05-0234-1 cases), so removing that definition is not going to work.
+>
+> Probably this case gets left in AI05-0234-1, and we'll let Steve get
+> it exactly right.
+>
+> The static case probably should get dumped into AI05-0235-1, since it
+> is at least as closely related to that.
+>
+> Thoughts??
+
+I agree this doesn't really have much to do with AI-234.
+But based on the above, I think we don't actually need AI-235 any more.  The
+only change I think we need is to 19.2/3, so really we are re-opening AI-142,
+and perhaps that is what AI-235 really is -- fixes to AI-142.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, February 14, 2011  8:57 PM
+
+> > So probably we should just replace 3.10.2(19.2/3) with something like:
+> >
+> > Inside a return statement that applies to a function F, when
+> > determining whether the accessibility level of an
+> explicitly aliased
+> > parameter of F is statically deeper than the level of the return
+> > object of 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, the
+> level of an
+> > explicitly aliased parameters of F is considered to be the
+> same as that of a local object of F.
+>
+> That sounds about right.
+
+OK. But then you go way off the rails below.
+
+> > Aside about AI05-0235-1: It appears that the old wording for
+> > parameters was intended to have a double meaning -- it
+> seems to mean
+> > something different for static and dynamic accessibility. Since we
+> > rewrote the paragraph to make sense for dynamic
+> accessibility, it no
+> > longer works for static accessibility (the levels aren't statically
+> > nested, so we can't apply 3.10.2(18)). I wonder if we need
+> a more general bullet for parameters:
+> >
+> > * Unless otherwise specified, the accessibility level of a formal
+> > parameter of a callable entity is considered to be the same
+> as that of
+> > a local object of F.
+>
+> I'm not sure why we need the "unless otherwise specified" any more.
+
+Because we still have the exception about "inside a return statement" in
+3.10.2(19.2/3). We don't want conflicting rules for them.
+
+I also will repeat that this is in *addition* to the rewording proposed in
+3.10.2(7/2). Maybe we can come up with a better rewording for the existing
+paragraph, so we don't need this extra bullet, but this one is purely intended
+to be a static check. We *always* need a dynamic level defined as well.
+
+...
+> > I don't think we want to mess with the dynamic accessibility rules.
+> > I strongly object to having a context-dependent dynamic
+> > accessibility
+> > check: I don't think there are any cases currently -- the value is
+> > always determined by the entity being checked. It sounds like a pain
+> > to implement context-specific checks (given these can be nested in
+> > many levels of calls and allocators).
+>
+> I *think* we are agreeing here, namely we should get rid of 13.3/3,
+> and make the change you suggested above to 19.2/3.
+
+No, because both the static and dynamic checks are applied to all entities.
+(Generally, the compiler can prove that one or the other aren't needed.) In
+particular, none of the rules about the dynamic check say anything about not
+applying them if the static check succeeds.
+
+So, the exception in 3.10.2(19.2/3) eliminates the static check within the
+return statement. But the dynamic check would then fail if we didn't have a
+special definition for the dynamic level for explicitly aliased parameters
+(because they would be treated as local objects). So we need the rules for the
+dynamic level for explicitly aliased parameters (since these are shallower than
+the "normal" parameter levels, it shouldn't require any additional checks or
+overhead, other than for AI05-0234-1 which has that effect for everything).
+
+> > I think Steve is trying to address this case, so my question is OBE.
+> > So I recommend leaving 3.10.2(13.3/3) [modulo changing it to use
+> > Steve's "ultimate accessibility level" rather than "the level that
+> > the return object will ultimately have", which is the same thing,
+> > but the former is worded more formally].
+>
+> Why do we need paragraph 13.3/3 any more?
+
+See above.
+
+> > Note that the dynamic check is definitely needed in these cases (the
+> > AI05-0234-1 cases), so removing that definition is not going to work.
+> >
+> > Probably this case gets left in AI05-0234-1, and we'll let Steve get
+> > it exactly right.
+> >
+> > The static case probably should get dumped into AI05-0235-1, since
+> > it is at least as closely related to that.
+> >
+> > Thoughts??
+>
+> I agree this doesn't really have much to do with AI-234.
+> But based on the above, I think we don't actually need AI-235 any
+> more.  The only change I think we need is to 19.2/3, so really we are
+> re-opening AI-142, and perhaps that is what
+> AI-235 really is -- fixes to AI-142.
+
+Now I'm very confused. The change in AI05-0235-1 was because the wording in
+3.10.2(7/2) is vague and conflicts with both 3.10.2(13.3/3 and 19.2/3). I
+suggested adding a new bullet to the static rules after removing the vagueness
+from 3.10.2(7/2) -- it appears to me that the reason it is vague was so that it
+could be two completely different meanings for dynamic and static accessibility
+levels -- but that is nasty and I much prefer having these things make sense.
+
+Somehow you've turned that into abandoning AI05-0142-4 (because the entire point
+is in the rules 3.10.2(13.3/3) and 3.10.2(19.2/3)) and leaving the impossibility
+to understand in 3.10.2(7.2). I've lost you here.
+
+I think it is fine to repurpose AI05-0235-1 to fix this problem, but not to
+ignore the problems or abandon the efforts on aliased parameters.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, February 14, 2011  9:22 PM
+
+I think we will need to carry this discussion over to the ARG meeting.  In my
+experience, these accessibility questions need to be worked on a white-board,
+perhaps in a group, and maybe with a beer or two handy...  In any case, I do see
+most of your points, I just haven't got the stamina to work through this further
+at this point.  I suggest you write up what you have in mind.  It may be fine.
+I was perhaps vainly hoping that we could simplify this a bit.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, February 14, 2011  9:32 PM
+
+OK, I admit I'm running out of stamina on this one, too. I think we might need a
+keg of beer, though. ;-) [I'd suggest Rochfort 10. :-)]
+
+I'm thinking that maybe there is a way to reword 3.10.2(7/2) that doesn't
+include "invocation" (which is what messes up the static accessibility level). I
+think my clunky wording didn't have that problem, but your improved wording
+messed that up (even though I much prefer it to mine). If that works, then at
+least we would only need to change two paragraphs.
+
+****************************************************************
```

Questions? Ask the ACAA Technical Agent