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;
+
+****************************************************************
+
+
Questions? Ask the ACAA Technical Agent