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

--- ai05s/ai05-0024-1.txt	2007/05/19 05:10:26	1.6
+++ ai05s/ai05-0024-1.txt	2007/05/24 04:54:56	1.7
@@ -1,4 +1,4 @@
-!standard 4.8(10/1)                                07-05-18    AI05-0024-1/02
+!standard 4.8(10/1)                                07-05-23    AI05-0024-1/03
 !standard 3.10.2(14-14.3/2)
 !class binding interpretation 06-11-13
 !status work item 06-11-13
@@ -135,10 +135,27 @@
     
 Add an AARM Note after 4.8(10.1/2):
   AARM NOTE: We can't use the normal accessibility level "deeper than" check
-    here because we may have "incomparable" levels.  This can happen when an
-    allocator initialized by a parameter passed in to an accept statement is
-    performed using an access type declared in the enclosing task body.
+    here because we may have "incomparable" levels. This can happen when
+    checking the accessibility of the tag for an allocator initialized by
+    a parameter passed in to an accept statement, if the type of the allocator
+    is an access type declared in the enclosing task body. For example:
+
+    task body TT is
+      type Acc_TC is access T'Class;
+      P : Acc_TC;
+    begin
 
+      accept E(X : T'Class) do
+         P := new T'Class'(X);  
+            -- accessibility check on tag of X
+            -- can't use "levels" since they
+            -- might be incomparable.  Must revert
+            -- to checking that the master
+            -- of the type identified by X'tag 
+            -- includes the elaboration of
+            -- Acc_TC, so it is sure to outlive it.
+      end E;
+ 
 Modify 6.5(8/2) as follows:
 
     If the result type of a function is a specific tagged type, the tag of the
@@ -2447,5 +2464,104 @@
 that is a mess.)
 
 ****************************************************************
+
+From: Robert A. Duff
+Date: Saturday, May 19, 2007  10:26 AM
+
+> The second sentence of the AARM note 4.8(10.1/2) reads:
+> "This can happen when an allocator initialized by a parameter passed in to
+> an accept statement is performed using an access type declared in the
+> enclosing task body."
+> 
+> I used to think that AARM notes were supposed to *help* the reader. What the
+> heck is "an allocator ... is performed using an access type..."?
+
+I think it means that the type of the allocator is "an access type blah
+blah...".  In other words, we're talking about "new T'(X)" appearing inside an
+accept statement, where X is a parameter passed in to that accept statement,
+and the result type of "new T'(X)" is a type declared in the task body
+enclosing that accept statement.
+
+>... I don't
+> think I've ever "performed" an allocator. :-)
+
+I think it's just being used as a synonym for "executed" or "evaluated" or
+whatever.
+
+****************************************************************
+
+From: Tucker Taft
+Date: Saturday, May 19, 2007  3:16 PM
+
+Yes, Bob managed to correctly translate my note into RM-ese.
+Sorry it was so sloppy.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Wednesday, May 23, 2007  7:08 PM
+
+> Yes, Bob managed to correctly translate my note into RM-ese.
+> Sorry it was so sloppy.
+
+Well, Bob tried to explain what was meant, but I still don't see how
+to write an AARM note with that meaning. Nor do I see precisely what
+the problem is in this case.
+
+Bob wrote:
+
+...
+>> The second sentence of the AARM note 4.8(10.1/2) reads:
+>> "This can happen when an allocator initialized by a parameter passed in to
+>> an accept statement is performed using an access type declared in the
+>> enclosing task body."
+> 
+> I think it means that the type of the allocator is "an access type blah
+> blah...".  In other words, we're talking about "new T'(X)" appearing inside an
+> accept statement, where X is a parameter passed in to that accept statement,
+> and the result type of "new T'(X)" is a type declared in the task body
+> enclosing that accept statement.
+
+X is copied in this case, so I don't see why there would be an accessibility
+check. I'm sure there is a reason, but I think an example and a short
+explanation would be far more valuable than trying to explain the whole
+thing in words, leaving out half of the conditions needed (as often happens).
+
+I was going to fix this wording up in the AI so we don't get bogged down with
+it. But I can't find an appropriate example in the mail, either. If I've
+already forgotten what the example is, imagine how mysterious this will be
+for the ARG 10 years from now. So if someone can provide an example, please
+do so. Thanx.
+
+****************************************************************
+
+From: Tucker Taft
+Date: Wednesday, May 23, 2007  11:20 PM
+
+  ... This can happen when checking the accessibility
+  of the tag for an allocator initialized by a parameter
+  passed in to an accept statement, if the type of the 
+  allocator is an access type declared in the enclosing 
+  task body.  For example:
+
+    task body TT is
+      type Acc_TC is access T'Class;
+      P : Acc_TC;
+    begin
+
+      accept E(X : T'Class) do
+         P := new T'Class'(X);  
+            -- accessibility check on tag of X
+            -- can't use "levels" since they
+            -- might be incomparable.  Must revert
+            -- to checking that the master
+            -- of the type identified by X'tag 
+            -- includes the elaboration of
+            -- Acc_TC, so it is sure to outlive it.
+      end E;
+
+****************************************************************
+
+