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

--- ai05s/ai05-0026-1.txt	2006/11/14 01:19:19	1.1
+++ ai05s/ai05-0026-1.txt	2007/04/06 04:37:11	1.2
@@ -1,4 +1,4 @@
-!standard B.3.3(9/2)                                   06-11-13    AI05-0026-1/01
+!standard B.3.3(9/2)                                   07-04-05    AI05-0026-1/02
 !standard B.3.3(10/2)
 !standard B.3.3(12/2)
 !class binding interpretation 06-11-13
@@ -10,7 +10,7 @@
 !subject Missing rules for Unchecked_Unions
 !summary
 
-TBD.
+A variant component type of an Unchecked_Union type shall not need finalization.
 
 !question
 
@@ -41,9 +41,105 @@
 
 !wording
 
-TBD.
+Insert after 7.6(9.4/2)
 
+   - it is a private type whose full view needs finalization; or
+
+Replace B.3.3(9/2)
+
+   Any name that denotes a discriminant of an object of an unchecked union type
+   shall occur within the declarative region of the type.
+   
+with
+
+   Any name that denotes a discriminant of an object of an unchecked union type
+   shall occur within the declarative region of the type, and shall not
+   occur within a record_representation_clause.
+
+
+Replace B.3.3(10/2)
+
+   A component declared in a variant_part of an unchecked union type shall
+   not have a controlled, protected, or task part.
+
+with
+
+   The type of a component declared in a variant_part of an unchecked union
+   type shall not need finalization. 
+   In addition to the places where Legality Rules normally apply (see 12.3),
+   this rule also applies in the private part of an instance of a generic unit.
+   For an unchecked union type declared within the body of a generic unit, or
+   within the body of any of its descendant library units, no part of the type
+   of a component declared in a variant_part of the unchecked union type shall
+   be of a formal private type or formal private extension declared within the
+   formal part of the generic unit.
+
+   
 !discussion
+
+The 7.6 addition is needed in order to make it clear that the definition
+of "needs finalization" looks through privacy. In a "static semantics"
+section, privacy is respected by default; if we want to ignore privacy,
+then this must be stated explicitly.
+
+It is intended that the new 10/2 formulation be equivalent (for purposes of
+Legality Checking of Unchecked_Union pragmas) to changing the definition
+of "needs finalization" to conservatively assume within a generic body
+that a generic formal private type or private extension "needs finalization".
+
+We don't actually make this change because that would interact badly with
+the rules for the No_Nested_Finalization restriction. We want to treat
+generic formal types conservatively in one case but not the other because
+No_Nested_Finalization restriction checking is a post-compilation check while
+legality checking for an Unchecked_Union pragma is not.
+
+B.3.3(7/2)'s requirement that "All component subtypes of an unchecked union
+type shall be C-compatible" typically eliminates 99% of the problems in this
+area anyway, but we don't want to rely on that.
+
+It is intended that this wording should handle the case of a formal private
+type (or a formal private extension) of a formal package. In this example,
+ 
+  declare
+    generic
+      type T is private;
+    package G1 is
+    end G1;
+
+    generic
+      with package I1 is new G1 (<>);
+    package G2 is
+    end G2;
+
+    package body G2 is
+      type U_U (D : Boolean) is
+        record
+          case D is
+            when False =>
+              null;
+            when True =>
+              F : I1.T;
+          end case;
+        end record;
+      pragma Unchecked_Union (U_U);
+    end G2;
+  begin
+    null;
+  end;
+      
+, the pragma should be rejected even if the implementation is willing
+to permit I1.T as a C-compatible type (using the freedom granted by B.1(20)).
+
+--------
+
+questions:
+1)  The wording "or within the body of any of its descendant library units"
+    follows the wording of 3.9.1(4/2). Alternatively, 4.8(5.3/2) uses
+    "or within a body declared within the declarative region of [the] generic
+    unit". Is one preferable to the other in this case?
+    
+    Incidentally, it appears that 10.2.1(10.1/2) has problems in this area and
+    doesn't handle nested generics or generic child units very well.
 
 --!corrigendum A.18.2(239/2)