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

Differences between 1.1 and version 1.2
Log of other versions for file ai05s/ai05-0068-1.txt

--- ai05s/ai05-0068-1.txt	2007/10/23 23:55:14	1.1
+++ ai05s/ai05-0068-1.txt	2007/12/13 04:39:37	1.2
@@ -1,13 +1,14 @@
-!standard 3.9.3(3/2)                                        07-10-23    AI05-0068-1/01
+!standard 3.9.3(3/2)                                        07-11-29    AI05-0068-1/02
 !standard 3.9.3(4/2)
 !standard 3.9.3(5/2)
 !standard 3.9.3(6/2)
-!class binding interpretation 07-10-23
+!class ramification 07-11-10
+!status ARG Approved  9-0-0  06-11-10
 !status work item 07-10-23
 !status received 07-10-11
 !priority Medium
 !difficulty Hard
-!qualifier Error
+!qualifier Clarification
 !subject Inherited subprograms may be both abstract and requires overriding
 
 !summary
@@ -36,7 +37,7 @@
         with Q;
         package R is
  	   type T2 is new Q.T with null record;
- 	   -- Legal? Op inherited here, but how?
+ 	   -- Legal? (No.) Op inherited here, but how?
  	end R;
 
 3.9.3(4/2) talks about types, not views. That would seem to imply that Q.Op is "requires
@@ -47,18 +48,15 @@
 overriding provided, Q.Op would have been abstract and R would be illegal (because the
 inherited routine would require overriding, but no overriding is given).
 
-Is this privacy breakage intended??
+Is this privacy breakage intended?? (No.)
 
-!recommendation
+!response
 
-(See Summary.)
+Generally, when we say "type" (or "object") in the Standard, we really mean "view of the type"
+(or "view of the object"). That's especially true for Legality Rules, because the compiler can
+really only know about views. Anything else would break privacy. Therefore there is nothing
+wrong with the wording.
 
-!wording
-
-Modify 3.9.3(4/2) to say "If {a view of} a type..."
-
-!discussion
-
 3.9.3(3/2) does not help in this case; it applies only to explicit abstract declarations.
 If it applied to inherited ones, then package Q would be illegal, and obviously we don't
 want that.
@@ -69,7 +67,7 @@
 illegal since it is an unrelated unit, but if R was renamed to be a private child of Q,
 then it would be legal.
 
-This may cause other problems. One rule that has been mentioned is 8.5.4(5.1/2): renaming
+This has other unusual effects. One rule that has been mentioned is 8.5.4(5.1/2): renaming
 a "requires overriding" subprogram is illegal (this is the so-called "squirreling rename").
 Given the fact that abstractness depends on the view:
 
@@ -87,15 +85,9 @@
 The first rename is legal because it is renaming an abstract subprogram, the second is
 illegal because it is renaming a "requires overriding" subprogram.
 
-[Steve Baird will tell us how this interacts with generic units with abstract private types
-to cause something unspeakable. ;-)]
-
---!corrigendum 7.6.1(17.1/1)
-
 !ACATS Test
 
-An ACATS test should ensure that remote access types are allowed (it seems likely that
-one exists).
+An ACATS B-test like the example in the question would be valuable.
 
 !appendix
 

Questions? Ask the ACAA Technical Agent