CVS difference for ai12s/ai12-0027-1.txt

Differences between 1.3 and version 1.4
Log of other versions for file ai12s/ai12-0027-1.txt

--- ai12s/ai12-0027-1.txt	2012/06/07 00:54:06	1.3
+++ ai12s/ai12-0027-1.txt	2012/07/17 23:29:48	1.4
@@ -1,4 +1,5 @@
-!standard 12.5.3(8)                                 12-06-04    AI12-0027-1/01
+!standard 4.6(8/2)                                   12-07-15    AI12-0027-1/02
+!standard 4.6(24.8/2)
 !class binding interpretation 12-06-04
 !status work item 12-06-04
 !status received 12-04-09
@@ -7,7 +8,8 @@
 !subject Contract violation for aliased components of actuals for formal array types
 !summary 
 
-**TBD.
+An additional "assume-the-worst" Legality Rule is adopted to avoid the problem noted
+in the question.
 
 !question
 
@@ -27,11 +29,29 @@
 
 !recommendation
 
-** TBD.
+(See summary.)
 
 !wording
 
-** TBD.
+append to 4.6(8/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.
+
+TBD: do we need similar boilerplate for 21/3 and 24/3? Let's wait
+     until a need is demonstrated.
+
+append after 4.6(24.8/2), as another bulleted list item:
+
+   - if the Target_Type of a view conversion is a generic formal array
+     type of a generic unit G that does not have aliased components, then
+     the conversion shall not occur within the body of G, nor within the
+     body of a generic unit declared within the declarative region of G.
+
+TBD: this is the 4th occurrence of this somewhat opaque "within the
+      body of a of a generic unit declared within" wording. See 8.5.1,
+      8.5.4, and 12.6. Do we want to define a term like "the extended
+      body" of a generic unit and then use that term in these 4 places?
 
 !discussion
 
@@ -61,20 +81,19 @@
 in the rules). So perhaps we don't need the strong conversion rule. But this
 seems like a large can of worms to open up.
 
-All-in-all, (3) seems to be the least of the evils, especially as this case
-is likely to be rare. (1) would prevent the Ada.Containers.Generic_Array_Sort
+We chose (2), as this avoids any run-time overhead. Any such type conversions
+could be moved to the specification as a workaround, using a helper "expression
+function". (3) would require run-time overhead for this rare case (although it
+would be limited to the case itself unless generic code sharing is used by
+the implementation). (1) would prevent the use of Ada.Containers.Generic_Array_Sort
 with arrays of aliased components, which seems insane given that procedure
-probably don't use any problematic type conversions. (2) prevents the use
-of the type conversions at all; moving them to the specification would be
-the only workaround, but that would at least require defining a helper
-"expression function" in the specification. (At least there would be an
-Ada 2012 workaround; there would be none in earlier versions of Ada.)
+probably doesn't use any problematic type conversions.
 (4) just seems too dangerous (and eliminating the type conversion rule was
 considered and rejected for Ada 2005, so it seems likely that it is still need).
 
 !ACATS test
 
-** TBD.
+An ACATS B-Test should be created to test these rules.
 
 !appendix
 

Questions? Ask the ACAA Technical Agent