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

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

--- ai05s/ai05-0081-1.txt	2008/01/17 07:24:41	1.1
+++ ai05s/ai05-0081-1.txt	2008/03/07 06:15:19	1.2
@@ -1,5 +1,6 @@
-!standard 4.8(5.1/2)                                           08-01-16    AI05-0081-1/01
+!standard 4.8(5.1/2)                                           08-02-25    AI05-0081-1/02
 !class binding interpretation 08-01-16
+!status deleted 08-02-25
 !status work item 08-01-16
 !status received 08-01-10
 !priority Low
@@ -9,47 +10,10 @@
 
 !summary
 
-(See Subject.)
+This AI has been merged into AI05-0052-1.
 
 !question
 
-In an instance, 12.3(11) says that the Legality Rules are normally
-checked in the visible part of an instance, but not the private part.
-However, there are lots of Legality Rules that the RM says are also
-checked in the private part.  
-
-Should 4.8(5.1) be one of those?  It looks like a possible oversight
-that it isn't.
-
-    package Pak1 is
-
-       type Root is tagged null record;
-       type Root_Acc is access all Root'Class;
-
-       generic
-          type T is new Root with private;
-          Init : T;
-       package Gen_Pack is
-       private
-          X : Root_Acc := new T' (Init);
-       end Gen_Pack;
-
-    end Pak1;
-
-
-    with Pak1;
-    procedure Proc1 is
-       type Child is new Pak1.Root with record ... end record;
-       Child_Init : constant Child := ...;
-       package Inst is new Pak1.Gen_Pack (Child, Child_Init);
-    begin
-       ...
-    end Proc1;
-
-With the current wording of the Standard, it appears that the instance
-would be illegal if X were in the visible part of Gen_Pack; but with X
-in the private part, the program is legal but will raise an exception
-at runtime. There doesn't seem to be a good reason for this difference.
 
 !recommendation
 
@@ -57,133 +21,12 @@
 
 !wording
 
-Add at the end of 4.8(5.1/2) and 4.8(5.2/2):
-
-In addition to the places where Legality Rules normally apply (see 12.3),
-this rule applies also in the private part of an instance of a generic unit. 
-
 !discussion
-
-This appears to be an oversight. There doesn't seem to be any benefit in
-postponing detection of an error from compile-time to run-time.
 
-A more interesting question is whether this should also apply to 4.8(5.2/2).
-It appears it should as well, for similar reasons.
+--!corrigendum 4.8(5.1/2)
 
-It would be nice to factor this wording out and have it apply to all of the
-Legality Rules of 4.8. However, because of the special body rules for
-4.8(5.3/2), it seems that it would be confusing (the boilerplate would apply to
-all of the rules; the special wording only to the last one).
 
---!corrigendum 13.9(7)
-
-
 !ACATS Test
 
 !appendix
-
-!topic Should 4.8(5.1) be checked in the private part of an instance?
-!reference RM05 4.8(5.1), 12.3(11)
-!from Adam Beneschan 08-01-10
-!discussion
-
-In an instance, 12.3(11) says that the Legality Rules are normally
-checked in the visible part of an instance, but not the private part.
-However, there are lots of Legality Rules that the RM says are also
-checked in the private part.  
-
-Should 4.8(5.1) be one of those?  It looks like a possible oversight
-that it isn't.
-
-    package Pak1 is
-
-       type Root is tagged null record;
-       type Root_Acc is access all Root'Class;
-
-       generic
-          type T is new Root with private;
-          Init : T;
-       package Gen_Pack is
-       private
-          X : Root_Acc := new T' (Init);
-       end Gen_Pack;
-
-    end Pak1;
-
-
-    with Pak1;
-    procedure Proc1 is
-       type Child is new Pak1.Root with record ... end record;
-       Child_Init : constant Child := ...;
-       package Inst is new Pak1.Gen_Pack (Child, Child_Init);
-    begin
-       ...
-    end Proc1;
-
-It appears that the instance would be illegal if X were in the visible
-part of Gen_Pack; but with X in the private part, the program is legal
-but will raise an exception at runtime.  There doesn't seem to be a
-good reason for this.  (GNAT rejects this program, by the way.)
-
-****************************************************************
-
-From: Randy Brukardt
-Sent: Thursday, January 10, 2008  9:06 PM
-
-> In an instance, 12.3(11) says that the Legality Rules are normally
-> checked in the visible part of an instance, but not the private part.
-> However, there are lots of Legality Rules that the RM says are also
-> checked in the private part.
-
-I don't think there is much doubt that we got the default wrong on this; it
-should always be checked in the private part unless there is a rule that
-says it is not. But it is waaayyy too late to make that kind of change.
-
-> Should 4.8(5.1) be one of those?  It looks like a possible oversight
-> that it isn't.
-
-Most certainly. There are probably only a handful of rules in the entire
-standard that it shouldn't apply to. Of course, there are many where it does
-not matter either way.
-
->     package Pak1 is
->
->        type Root is tagged null record;
->        type Root_Acc is access all Root'Class;
->
->        generic
->           type T is new Root with private;
->           Init : T;
->        package Gen_Pack is
->        private
->           X : Root_Acc := new T' (Init);
->        end Gen_Pack;
->
->     end Pak1;
->
->
->     with Pak1;
->     procedure Proc1 is
->        type Child is new Pak1.Root with record ... end record;
->        Child_Init : constant Child := ...;
->        package Inst is new Pak1.Gen_Pack (Child, Child_Init);
->     begin
->        ...
->     end Proc1;
->
-> It appears that the instance would be illegal if X were in the visible
-> part of Gen_Pack; but with X in the private part, the program is legal
-> but will raise an exception at runtime.  There doesn't seem to be a
-> good reason for this.  (GNAT rejects this program, by the way.)
-
-I suspect GNAT is just following good sense here.
-
-****************************************************************
-
-From: Pascal Leroy
-Sent: Friday, January 11, 2008  1:35 AM
-
-I can't verify this, but I suspect that the IBM compiler also rejects this code.
-
-****************************************************************
 

Questions? Ask the ACAA Technical Agent