CVS difference for ais/ai-00344.txt

Differences between 1.20 and version 1.21
Log of other versions for file ais/ai-00344.txt

--- ais/ai-00344.txt	2005/08/21 06:00:30	1.20
+++ ais/ai-00344.txt	2005/10/31 05:18:31	1.21
@@ -3161,3 +3161,118 @@
 
 ****************************************************************
 
+From: Gary Dismukes
+Sent: Wednesday, April 13, 2005  2:11 AM
+
+While working on the implementation of AI-344 (Nested Type Extensions),
+I noticed what appear to be a couple of gaps in the rules having to do
+with accessibility checks for allocators.  The cases I'm concerned with
+have to do with contract model problems for generics.  Specifically, this
+occurs in situations where the type of the allocator is a formal access type
+and the allocator has a subtype indication.  The run-time check defined in
+4.8(7/2) is defined to apply only in the case of allocators with qualified
+expressions.  Normally that's sufficient since in the case of an allocator
+with a subtype indication, the subtype has to denote a specific tagged type,
+and so the accessibility level check can be done statically.  However, in
+the case of an allocator of a formal access type, the level of the actual
+isn't known when the generic template is compiled.  This leads to a contract
+hole when such an allocator appears in the generic body.  This could be
+addressed by an assume-the-worst rule (and without creating incompatibilities),
+but it seems better to handle this by a run-time check.  I suggest that this
+be done by extending the rule of 4.8(7/2) to cover the case of allocators
+with subtype indications:
+
+  If the designated type of the type of the allocator is class-wide, then
+  a check is made that the accessibility level of {the type determined by
+  the subtype indication or} the type identified by the tag of the value
+  of the qualified_expression is not deeper than that of the type of the
+  allocator. Program_Error is raised if this check fails.
+
+A somewhat related issue occurs for allocators within the private part of
+a generic.  It seems reasonable for the static accessibility check of
+paragraph 4.8(5.1/2) to apply to such allocators.  But then it's necessary
+to have an explicit statement that the rule applies within the private part
+of an instance of the generic.  We could handle this case by the run-time
+check of 4.8(7/2) (assuming it's extended as discussed above), but it seems
+more consistent to catch the private part cases by enforcing the static
+accessibility check on private parts of instances.
+
+Assuming I'm not overlooking something that addresses these issues already,
+I'd like to have discussion of the proposed fixes to AI-344 added to the
+agenda for the upcoming meeting.
+
+Here's a small example to illustrate:
+
+   package Pkg is
+      type TT0 is tagged null record;
+      type Acc_TT0_Class is access all TT0'Class;
+   end Pkg;
+
+   procedure Proc is
+
+      type TT1 is new Pkg.TT0 with record
+         I : Integer;
+      end record;
+
+      generic
+         type Formal_Acc_TT0_Class is access all Pkg.TT0'Class;
+      package Gen_2 is
+
+      private
+         A1 : Formal_Acc_TT0_Class := new Nested_Extension;
+            --  Legal in template.
+            --  Should this be illegal in instance if it violates 4.8(5.1/2)?
+            --  If 4.8(5.1/2) does not apply, then a run-time check should
+            --  apply, as per suggested extension of 4.8(7/2).
+
+         A2 : Formal_Acc_TT0_Class := new Nested_Extension'(I => 123);
+            --  Legal in template.
+            --  Should this be illegal in instance if it violates 4.8(5.1/2)?
+            --  If 4.8(5.1/2) does not apply, then will be caught by the
+            --  the current run-time check of 4.8(7/2).
+      end Gen_2;
+
+      package body Gen_2 is
+         A3 : Formal_Acc_TT0_Class := new Nested_Extension;
+            --  Legal in template.
+            --  No run-time check occurs by current 4.8(7/2), but this
+            --  is a contract model violation.
+
+         A4 : Formal_Acc_TT0_Class := new Nested_Extension;
+            --  Legal in template.
+            --  Run-time check will occur due to current 4.8(7/2).
+      end Gen_2;
+
+      package New_Gen_2_A is new Gen_2 (Pkg.Acc_TT0_Class);  -- Illegal?
+
+      package New_Gen_2_B is new Gen_2 (Local_Acc_TT0_Class);   -- Legal
+
+   begin
+      null;
+   end Proc;
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, April 13, 2005  8:39 AM
+
+I haven't reviewed what you wrote in depth yet, but be aware
+that AI-416 covered a lot of this material.  My last update to
+AI-416 was March 12th, and it was version 5.  This version
+is not on the ada-auth web site, and I don't know whether
+it has been incorporated into the draft revised RM.
+
+I'll compare what you wrote to AI-416 when I have some
+more spare brain cycles...
+
+****************************************************************
+
+From: Gary Dismukes
+Sent: Wednesday, April 13, 2005  2:23 PM
+
+AI-416 (v5) doesn't address or relate to this as far as I can see, but
+I may be missing something.  (Btw, don't go out of your way to invest
+spare cycles, it's not that important an issue.;)
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent