CVS difference for ai12s/ai12-0345-1.txt

Differences between 1.2 and version 1.3
Log of other versions for file ai12s/ai12-0345-1.txt

--- ai12s/ai12-0345-1.txt	2019/10/02 01:42:49	1.2
+++ ai12s/ai12-0345-1.txt	2020/01/14 04:56:53	1.3
@@ -1,6 +1,9 @@
-!standard 3.10.2(13.4/4)                                    19-09-30  AI12-0345-1/01
-!standard 13.11.4(21/3)
-!standard 13.11.4(31/3)
+!standard 3.10.2(5)                                    20-01-13  AI12-0345-1/02
+!standard 3.10.2(7/4)
+!standard 3.10.2(10.5/3)
+!standard 3.10.2(13.4/4)
+!standard 3.10.2(19.2/5)
+!standard 3.10.2(21)
 !class binding interpretation 19-09-30
 !status work item 19-09-30
 !status received 19-09-17
@@ -32,24 +35,65 @@
-Replace 3.10.2(13.4/4) with:
+Modify 3.10.2 (5):
-The accessibility level of an explicitly aliased (see 6.1) formal parameter 
-in a function body the same as any other formal parameter, except that it is
-defined to match the level of the master of the call when compared to the
-level of the return object of the function.
-AARM Reason: We make checks on the actual object for an explicitly aliased
-parameter of a function to ensure that it can be returned, so we define that
-no checks are ever needed in that case. For all other uses, it acts the same
-as any other parameter (that is, it is treated as local to the function).
-AARM Implementation Note: If the dynamic level of an explicitly aliased 
-parameter is needed for some purpose, it is local to the function -- it is 
-never necessary to pass in the actual level of the call for explicitly aliased 
-parameters. Note that the matching defined here can be implemented by simply
-omitting any check in the case where one is matching an explicitly aliased
-parameter to the master of the call.
+  Each master, and each entity and view created by it, has an
+  accessibility level{; when two levels are defined to be the same, the
+  accessibility levels of the two associated entities are said to be
+  *tied* to each other}:
+Modify 3.10.2 (7/4):
+   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]{A} formal parameter of a callable
+   entity has the same accessibility level as the master representing
+   the invocation of the entity. 
+Delete AARM 3.10.2(10.d.6/3):
+   - when the function has an explicitly aliased parameter. 
+Modify 3.10.2(10.5/3):
+   If the call itself defines the result of a function to which one of the 
+   above rules applies,{ or has an accessibility level that is tied to the 
+   result of such a function,} these rules are applied recursively;
+Delete 3.10.2(13.4/4):
+   The accessibility level of an explicitly aliased (see 6.1) formal
+   parameter in a function body is determined by the point of call; it
+   is the same level that the return object ultimately will have.
+Delete 3.10.2(19.2/5):
+   Inside a return statement that applies to a function or generic function F,
+   or inside the return expression of an expression 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 a parameter of F that is
+   not explicitly aliased the body of F.
+Delete AARM 3.10.2(19.b/3):
+   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).
+Add after 3.10.2(21):
+Notwithstanding other rules given above, the accessibility level of an entity 
+that is tied to that of an explicitly aliased formal parameter of an enclosing 
+function is considered (both statically and dynamically) to be the same as 
+that of an entity whose accessibility level is tied to that of the return object 
+of that function.
+AARM Ramification: This rule only applies when the level of an explicitly 
+aliased parameter of a function is compared to that of the return object of 
+the function. If a value designating the explicitly aliased parameter is
+created and stored in a stand-alone object or passed as a parameter, this
+special property is lost (even for the dynamic accessibility of anonymous
+access types in these contexts).
@@ -72,29 +116,90 @@
 accessibility of an explicitly aliased parameter, and thus it would need to be
-Therefore, we reword the dynamic accessibility of explicitly aliased parameters
-to match the intended model exactly.
+After a number of unsuccessful rewordings, we settled on the notion of two
+accessibility levels being "tied". When two tied levels are compared, the check
+always must pass (and a compiler should generate no check).
+The model is that this is ONLY true when tied levels are known at compile-time
+to be compared. In particular, storing an access value derived from an
+explicitly aliased parameter in a stand-alone object of an anonymous access
+type, or passing such a value as an access parameter, loses the "tied" 
+property. In such cases, the dynamic accessibility of the parameter is local.
+Here are some examples to show some of the implications of these rules:
+    type Rec is record
+        Comp : aliased Integer;
+        ...
+    end record;
+    Glob : Boolean := ...;
+    function F1 (A : aliased in out Rec) return access Integer is
+       C : aliased Integer;
+       function F2 (B : access Integer) return access Integer
+          is (B); -- (1)
+    begin
+       if Glob then
+           return F2 (C'Access); -- Program_Error raised.
+       else
+           return F2 (A.Comp'Access); -- Program_Error raised.
+       end if;
+    end F1;
+The dynamic accessibility check at (1) should fail for either parameter
+passed to function F2. Even though the calls to F2 have the master of the
+call of F1, the special "tied to an explicitly aliased parameter" property
+is lost when the A.Comp'Access value is passed as a parameter.
+Contrast this to the similar case using explicitly aliased parameters:
+    function F4 (A : aliased in out Rec) return access Integer is
+       C : aliased Integer;
+       function F5 (B : aliased in out Integer) return access Integer
+          is (B'Access); -- (2)
+    begin
+       if Glob then
+           return F5 (C); -- Illegal.
+       else
+           return F5 (A.Comp); -- OK.
+       end if;
+    end F4;
+Here, (2) is both statically and dynamically checking "tied" accessibility 
+levels, so no check of either kind is needed at (2). That works in part as
+such checks are moved to the call site of F5. Thus, passing the local object
+C is illegal, the static accessibility check on explicitly aliased parameters
+fails here. OTOH, the static check for A.Comp succeeds by definition, as it 
+is comparing "tied" levels.
+The change to 3.10.2(10.5/3) is intended to handle cases were some part of the
+return value is returned. For instance:
-An alternative model was proposed where the dynamic accessibility of an 
-explicitly aliased parameter would be that of the return object, if the 
-implementation would have to pass the level along with a call. This model
-would also have no additional cost, but it would have a maintenance hazard,
-as the accessibility of the parameter could change if the return type is
-changed (possibly even if only the private components of some hidden part 
-of the return type is changed). This could cause working code to suddenly
-start raising Program_Error rather mysteriously.
-[Author's note: Steve's proposal makes large changes to the accessibility
-model for explicitly aliased parameters. That seems dangerous, accessibility
-is confusing enough without changing wording that we have some (small? :-)
-level of confidence in. I'd prefer to change as little as possible, especially
-as the intent was that no one could ever see the (real) dynamic accessibility 
-level of an explicitly aliased parameter.
+    function F7 (A : aliased in out Rec) return access Integer is
+       C : aliased Rec := ...;
+       function F8 (B : aliased in out Rec) return access Rec
+          is (B'Access);
+    begin
+       if Glob then
+           return F8 (C).Comp'Access; -- Illegal.
+       else
+           return F8 (A).Comp'Access; -- OK.
+       end if;
+    end F7;
+The accessibility of the calls to F8 are now that of F7. This makes the
+accessibility of the result sufficient to return from F7. It means that
+the static check on the parameter C fails as it is too nested for to be
-Steve didn't provide any of the examples that caused this discussion (I have
-to assume there were some, so it's impossible to tell if the "easy"]
+The old rule did not apply to this case as it said "used as the return"; here
+only a part of the return is used, and that part comes via a dereference. 
@@ -102,6 +207,8 @@
 !ACATS test
+A B-Test containing the examples above might be useful, as well as a C-Test
+that the special level does not persist.

Questions? Ask the ACAA Technical Agent