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

Differences between 1.6 and version 1.7
Log of other versions for file ai12s/ai12-0066-1.txt

--- ai12s/ai12-0066-1.txt	2017/04/21 05:43:52	1.6
+++ ai12s/ai12-0066-1.txt	2017/07/19 23:45:52	1.7
@@ -79,6 +79,36 @@
 
 Should this be fixed?
 
+(6) The wording of 12.2(2) isn't quite right.
+
+      If the generic body is a child of a generic package, then its
+      elaboration establishes that each corresponding declaration nested in
+      an instance of the parent (see 10.1.1) can from then on be
+      instantiated without failing the Elaboration_Check.
+
+Consider how this wording applies to the elaboration of the (one and only)
+generic body in this example:
+
+     generic package G1 is end;
+     generic package G1.G2 is end;
+     generic package G1.G2.G3 is pragma Elaborate_Body end;
+     package body G1.G2.G3 is end;
+
+     with G1;           package I1 is new G1;
+     with I1, G1.G2;    package I2 is new I1.G2;
+     with I2, G1.G2.G3; package I3 is new I2.G3;
+
+I3 is instantiating I2.G3 after the body of G1.G2.G3 has been elaborated.
+
+We want the elaboration check to pass, but this does not follow from a strict
+reading of the wording.
+
+In this context, the phrase "the parent" obviously refers to G1.G2. There are
+no instances of G1.G2 anywhere in this example. There is an instance of I1.G2,
+but that's not the same thing.
+
+Should this be fixed?
+
 !response
 
 For these questions, we believe that adding proper wording to the Standard
@@ -217,6 +247,40 @@
 relatively complicated and only useful for this construct, we choose not to
 fix this.
 
+(6) Fixing this probably would require a term (as the definition is recursive).
+Something like the following:
+
+  The "ultimate corresponding generic unit" of a generic unit G is defined to
+  be
+
+   If G is declared in an instance of another generic unit G2,
+   then the ultimate corresponding generic unit of G2.G;
+   otherwise G.
+
+Then the present wording could be fixed to use this new term:
+
+  If the generic body is a child of a generic package (see 10.1.1),
+  then its elaboration establishes that any generic unit whose
+  ultimate corresponding generic unit is that child unit
+  can from then on be instantiated without failing the Elaboration_Check.
+
+However, this isn't quite right, as it wouldn't cope properly with
+
+   generic package G1 is
+      package Nested_Nongeneric is
+          generic package G2 is
+          end;
+      end;
+   end;
+
+   package I1 is new G2;
+   package I2 is new I1.Nested_Nongeneric.G2;
+
+where the name G1.G2 doesn't make sense.
+
+This is complicated enough, and the likelyhood that anyone would get the wrong
+answer is low enough, that we don't attempt to fix it.
+
 !appendix
 
 From: Randy Brukardt
@@ -1151,6 +1215,117 @@
 name that denotes a variable"] while the other three don't use "be" at all.
 
 I love consistency like this. ;-)
+
+****************************************************************
+
+From: Steve Baird (privately, thread used by permission, edited to remove chit-chat)
+Sent: Tuesday, July 18, 2017  11:30 AM
+
+> Never mind, I found it in 12.2(2):
+> 
+>      If the generic body is a child of a generic package, then its
+>      elaboration establishes that each corresponding declaration nested in
+>      an instance of the parent (see 10.1.1) can from then on be
+>      instantiated without failing the Elaboration_Check.
+
+Incidentally, this wording isn't quite right.
+
+Consider how this wording applies to the elaboration of the (one and only)
+generic body in this example:
+
+     generic package G1 is end;
+     generic package G1.G2 is end;
+     generic package G1.G2.G3 is pragma Elaborate_Body end;
+     package body G1.G2.G3 is end;
+
+     with G1;           package I1 is new G1;
+     with I1, G1.G2;    package I2 is new I1.G2;
+     with I2, G1.G2.G3; package I3 is new I2.G3;
+
+I3 is instantiating I2.G3 after the body of G1.G2.G3 has been elaborated.
+
+We want the elaboration check to pass, but does this follow from a strict
+reading of the wording?
+
+In this context, the phrase "the parent" obviously refers to G1.G2. There
+are no instances of G1.G2 anywhere in this example. There is an instance of
+I1.G2, but that's not the same thing.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, July 18, 2017  12:39 PM
+
+You are right, seems like an ancestor or something. A fix is not clear to me
+(if it was, I'd suggest fixing it, but otherwise just leave it until it
+matters in practice).
+
+****************************************************************
+
+From: Steve Baird
+Sent: Tuesday, July 18, 2017  1:23 PM
+
+If we actually wanted to fix this, I'd suggest defining a new term.
+
+The "ultimate corresponding generic unit" of a generic unit G is defined to
+be something like
+
+   If G is declared in an instance of another generic unit G2,
+   then the ultimate corresponding generic unit of G2.G;
+   otherwise G.
+
+The precise name of the term is, as always, up for discussion.
+
+Then the present wording could be fixed to use this new term:
+
+  If the generic body is a child of a generic package (see 10.1.1),
+  then its elaboration establishes that any generic unit whose
+  ultimate corresponding generic unit is that child unit
+  can from then on be instantiated without failing the Elaboration_Check.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Tuesday, July 18, 2017  5:41 PM
+
+My use of G2.G wasn't quite right. The notion of the corresponding generic
+declared within the outer generic would have to be spelled out more
+explicitly to cope with something like
+
+   generic package G1 is
+      package Nested_Nongeneric is
+          generic package G2 is
+          end;
+      end;
+   end;
+
+   package I1 is new G2;
+   package I2 is new I1.Nested_Nongeneric.G2;
+
+where the name G1.G2 makes no sense. But you get the idea.
+
+As you pointed out earlier, the real question is whether this is worth fixing
+at all.
+
+I think leaving wording as is and adding an AARM note might be a reasonable
+choice, but even that is a tough call.
+
+If it ain't (sufficiently) broke ...
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, July 19, 2017  10:50 AM
+
+Maybe we should put file this thread in the AI of things we don't intend to
+fix??
+
+****************************************************************
+
+From: Steve Baird
+Sent: Wednesday, July 19, 2017  11:03 AM
+
+That sounds good to me.
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent