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

--- ai05s/ai05-0235-1.txt	2011/02/15 05:59:56	1.5
+++ ai05s/ai05-0235-1.txt	2011/03/05 05:35:02	1.6
@@ -1,7 +1,9 @@
-!standard  3.10.2(7/2)                             11-02-14    AI05-0235-1/03
+!standard  3.10.2(7/2)                             11-03-04    AI05-0235-1/04
 !standard  3.10.2(19.2/3)
 !reference AI05-0142-4
 !class Amendment 10-11-18
+!status Amendment 2012 11-03-04
+!status ARG Approved  5-0-3  10-02-19
 !status work item 10-11-18
 !status received 10-11-15
 !priority Low
@@ -49,20 +51,20 @@
 
 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]
+  {Other than for an explicitly aliased parameter, a}[A]
   {formal} parameter of [a master] {a callable entity} has the same
-  accessibility level as the master {that is the execution of the
-  called entity}.
+  accessibility level as the master {representing the invocation of the
+  entity}.
 
-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 To Be Honest: We use "innvocation of the entity" as a master is formally
+an execution of something. 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). 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
+accessibility level of the corresponding actual parameter. This occurs in
 other cases as well.
 
 AARM Reason: We define the (dynamic) accessibility of formal parameters in
@@ -74,14 +76,28 @@
 
 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.
+* 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.
+
+* 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 determined by the point of call is presumed to be the same
+  as that of the level of the master that elaborated the function body.
+
+AARM To Be Honest: This rule has no effect if the previous bullet also
+applies (that is, the "a level" is of an explicitly aliased parameter).
+
+[This latter bullet is from AI05-0051-1; it was replaced by early versions
+of the first bullet, but eventually they diverged and the point of this
+bullet was lost.]
 
+
 !discussion
 
 (1) The wording of 3.10.2(7/2) is quite vague. It is clear that it doesn't make
@@ -96,8 +112,58 @@
 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).
 
+!corrigendum 3.10.2(7/2)
+
+@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. A
+parameter of a master has the same accessibility level as the master.>
+@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, 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)
+!comment Really in the conflict file.
+
+@dinsa
+@xbullet<The statically deeper relationship does not apply to the accessibility
+level of the anonymous type of an access parameter specifying an
+access-to-object type; that is, such an accessibility level is not
+considered to be statically deeper, nor statically shallower, than
+any other.>
+@dinss
+@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 presumed 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>.>
+
+@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 determined by the point of call is presumed to be the same
+as that of the level of the master that elaborated the function body.>
+
 !ACATS Test
 
+This will be tested as part of the tests for AI05-0142-4.
+
+!ASIS
+
+No effect on ASIS.
+
+!appendix
+
 [The following is part of the discussion of AI05-0234-1 - Editor.]
 
 From: Steve Baird
@@ -1150,5 +1216,35 @@
 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.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Thursday, March 3, 2011  4:58 PM
+
+> Related to AI05-0235-1 (but would cause a new AI): Is there a problem 
+> with accessibility checks (especially dynamic ones) for explicitly 
+> aliased parameters of task entries?? Does this cause "comparability" problems??
+> 
+
+I think there is no problem here.
+
+Marking a parameter of a non-function (e.g., of an entry) as aliased just means, from
+the callee's perspective, that it can be treated in much the same way as an aliased
+local.
+
+The !summary section of AI05-0235 says
+   Explicitly aliased parameters have special accessibility only within
+   the return statement of a function; otherwise, they have the same
+   accessibility as "normal" parameters.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, March 4, 2011  10:28 PM
+
+To expand on this a bit: tagged types already can be used as the prefix of 'Access.
+So if there was a problem, it would already have appeared with such tagged parameters
+of an entry. Explicitly aliased parameters add nothing new vis-a-vis accessibility.
 
 ****************************************************************