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

--- ai05s/ai05-0115-1.txt	2008/10/16 04:02:31	1.1
+++ ai05s/ai05-0115-1.txt	2008/10/17 04:14:51	1.2
@@ -1,4 +1,4 @@
-!standard 4.3.1(14)                                         08-10-15  AI05-0115-1/01
+!standard 4.3.1(14)                                         08-10-16  AI05-0115-1/02
 !standard 4.3.2(5/2)
 !class binding interpretation 08-10-15
 !status work item 08-10-15
@@ -73,22 +73,10 @@
 
 If the type of a record_aggregate is a record extension, then it shall be a
 descendant of a record type, through one or more record extensions (and no
-private extensions). {Moreover, the parent type of each of those record extensions
-shall have been a record type or record extension at the point of the record
-extension declaration.}
-
-[Editor's Note: An alternative way of wording this would simply require that all
-components are visible. However, care would be needed to avoid making private types
-which are null records always legal, as that would break privacy. One way of wording
-that would be something like:
+private extensions). {Moreover, for each of those record extensions R, there
+shall exist some place in the immediate scope of the type R where the parent
+type of R is a record or record extension.}
 
-A record_aggregate is illegal if any possible components of the composite value
-defined by the type of the aggregate are not visible or not declared.
-
-It's not clear that this is any actual improvement; it's pretty vague about
-"possible components". It also doesn't work as well for the extension
-aggregate case. Thus I didn't use it. End Editor's Note.]
-
 AARM Note:
 
 The last sentence prevents aggregates where not all of the components are
@@ -135,9 +123,9 @@
 
 ... The type of the extension_aggregate shall be derived from the type of
 the ancestor_part, through one or more record extensions (and no private
-extensions). {Moreover, the parent type of each of those record extensions
-shall have been a record extension at the point of the record extension 
-declaration.}
+extensions). {Moreover, for each of those record extensions R,
+there shall exist some place in the immediate scope of the type R where
+the parent type pf R is a record or record extension.}
 
 !discussion
 
@@ -156,12 +144,51 @@
    R := (Root with C2 => 2, C3 => 3, others => 1); -- (Illegal.)
    R := (Root with others => 4);                   -- (Illegal.)
 
-[Editor's Second Note: I'm not completely convinced that there isn't some weird
+[Editor's Note: I'm not completely convinced that there isn't some weird
 case where the components get declared in the body. There are such cases for
 operations that are declared in nested packages, but I *think* that components
 don't have any such cases because a nested package can't add any components to
-an outer type. Steve Baird may prove me wrong...]
+an outer type. Steve Baird may prove me wrong...
+
+The proposed wording is completely opaque. I originally proposed
+
+  Moreover, the parent type of each of those record extensions
+  shall have been a record type or record extension at the point of the record
+  extension declaration.
+
+However, Steve Baird pointed out that this wording doesn't work for
+a record extension declared in the visible part of a child unit if the aggregate
+is given in the body of that unit -- in that case there is no problem, but this
+wording would make that illegal.
+
+I've attempted to patch this up by echoing the words of 7.3. But I'm not sure
+that that actually works, either. And it is completely inpenatrable: it doesn't
+explain the actual problem in any way.
+
+An alternative way of wording this would simply require that all
+components are visible. However, that doesn't work, because that would allow
+aggregates if the hidden parent type was a null record. That would be privacy
+breaking, as if any components were added later, the aggregate would then become
+illegal.
+
+One could try to work around that with wording like:
+
+A record_aggregate is illegal if any possible components of the composite value
+defined by the type of the aggregate are not visible or not declared.
+
+It's not clear that this is any actual improvement; it's pretty vague about
+"possible components". It also doesn't work for the extension
+aggregate case, where we only need to consider a subset of the components.
+
+A last way to solve this problem would be to allow the components to be visible
+in cases like those given in the question. In that case, no legality rule would
+be needed here. But conflicting components would have to be illegal when a type
+is declared, so there is some incompatibility. [Such a rule also would eliminate
+the issue raised in an AI that hasn't been written yet if it also applied to
+inherited subprograms. But that would be more incompatible.]
 
+End Editor's Note.]
+
 !corrigendum 4.3.1(14)
 
 @drepl
@@ -171,9 +198,9 @@
 @dby
 If the type of a @fa<record_aggregate> is a record extension, then it shall be a
 descendant of a record type, through one or more record extensions (and no
-private extensions). Moreover, the parent type of each of those record extensions
-shall have been a record type or record extension at the point of the record
-extension declaration.
+private extensions). Moreover, for each of those record extensions @i<R>,
+there shall exist some place in the immediate scope of the type @i<R> where the
+parent type of @i<R> is a record or record extension.
 
 !corrigendum 4.3.2(5/2)
 
@@ -188,9 +215,10 @@
 tagged subtype. If the @fa<ancestor_part> is an @fa<expression>, it shall
 not be dynamically tagged. The type of the @fa<extension_aggregate> shall
 be derived from the type of the @fa<ancestor_part>, through one or more
-record extensions (and no private extensions). Moreover, the parent type
-of each of those record extensions shall have been a record extension at
-the point of the record extension declaration.
+record extensions (and no private extensions). Moreover, for each of those
+record extensions @i<R>, there shall exist some place in the immediate
+scope of the type @i<R> where the parent type of @i<R> is a record or record
+extension.
 
 !ACATS Test
 
@@ -347,6 +375,63 @@
 
 ****************************************************************
 
+A brief summary of a private e-mail discussion between Steve Baird,
+Tucker Taft, and Randy Brukardt in October 2008 [discussing version /01
+of this AI].
+
+Steve:
+
+I think the following should be legal. Would your wording cause it to 
+be rejected?
+
+   package Parent is
+     type T0 is tagged null record;
+     type T1 is new T0 with private;
+   private
+     type T1 is new T0 with record
+       F1 : Integer;
+     end record;
+   end Parent;
+
+    package Parent.Child is
+      type T2 is new T1 with null record;
+    private
+      X2 : T2 := (F1 => 37);
+    end Parent.Child;
+
+The point is that, at the point of derivation, T2 was derived from a 
+private extension.
+
+Randy:
+
+You are correct, so my proposed wording doesn't work.
+Apparently, there isn't any idea that works (basing it on component visibility
+breaks privacy, because it would allow null records, and basing it on potential
+component visibility is just too goofy for words).
+
+Tucker:
+
+One interesting way to illustrate the problem would be for
+Pak2.T2 to have its *own* "C1" component, which would be legal.  
+Clearly the C1 component from T1 should never be visible in T3, even in its own body.
+
+Randy:
+
+True. That would be a bad example here, though, because it would make the named 
+notation aggregate illegal.
+
+I suppose one alternative would be to step back further and think about if we
+want to eliminate the privacy instead -- that is (given the other issues that
+Adam raised), perhaps we need to make the components visible in this case (and
+then we don't need a legality rule). Similarly with the inherited operations.
+But that would be incompatible.
+
+In an example like the one Tucker mentions, the declaration of T3 would have to be
+illegal as it would declare two components with the same name. That seems OK to
+me (it would be a better incompatibility than some sort of boujalias effect), but
+it clearly would break some code.
+
+****************************************************************