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

Differences between 1.2 and version 1.3
Log of other versions for file ai05s/ai05-0236-1.txt

--- ai05s/ai05-0236-1.txt	2011/02/08 08:21:06	1.2
+++ ai05s/ai05-0236-1.txt	2011/03/17 02:22:05	1.3
@@ -1,9 +1,10 @@
-!standard 10.2.1(10/2)                              11-01-26    AI05-0236-1/01
+!standard 10.2.1(10/2)                              11-03-16    AI05-0236-1/02
 !standard 10.2.1(10.1/2)
 !standard 10.2.1(11.1/2)
 !standard 10.2.1(11.2/2)
 !standard 10.2.1(11.4/2)
 !standard 10.2.1(11.8/2)
+!class confirmation 11-03-16
 !class binding interpretation 11-01-26
 !status work item 11-01-26
 !status received 10-10-28
@@ -45,17 +46,22 @@
     and T'First is not the name of an object
   * there's no default initialized object (9/3)
 
-So why is this illegal? (Dunno.)
+So is this legal? (Yes.)
 
-!recommendation
+!response
 
-(See Summary.)
+After much discussion, it was decided that these kinds of issues
+are not worth fixing. Yes, this means that some preelaborated
+units will need to execute code during elaboration. But this
+doesn't cause any logical problems.
 
-!wording
+In any case, fixing these kinds of issues would necessarily by
+incompatible, so we decided to live with these somewhat-questionable
+rules.
 
+Note that none of the examples trigger C.4(2-11), so the fact that they are
+dynamic is pretty much irrelevant.
 
-!discussion
-
 The problem appears to be much more pervasive than noted in the question.
 By the logic of the question, none of the following constants appear to be
 illegal:
@@ -91,30 +97,26 @@
 But then we went and built rules that completely violate that assumption.
 
 It's not clear how to fix this without making lots of things illegal that
-currently are legal. The easy solution:
+currently are legal. The easy solution of adding:
 
    * The elaboration or evaluation of a construct that includes a name
      denoting a non-static subtype.
 
-would pretty much prevent any use of generic formals other than inside of
-subprograms in a preelaborated generic. Moreover, it would prevent declaration
-of types involving components of formal types, which seems like going too
-far.
+to 10.2.1(5-9) would pretty much prevent any use of generic formals other than
+inside of subprograms in a preelaborated generic. Moreover, it would prevent
+declaration of types involving components of formal types, which seems like
+going too far.
 
 Enumerating the problem cases seem to lead us to a warren of holes.
-
-Finally, there is the option of doing nothing. None of the examples above
-trigger C.4(2-11), so the fact that they are dynamic is pretty much irrelevant.
 
-
---!corrigendum 10.2.1(9/2)
+!ACATS test
 
+None needed.
 
+!ASIS
 
-!ACATS test
+No change, so no ASIS impact.
 
-Better be some.
-
 !appendix
 
 From: Thomas Quinot
@@ -499,6 +501,205 @@
 Date: Thursday, January 27, 2011  9:50 AM
 
 You're right, I missed that.  Thanks.
+
+****************************************************************
+
+From: Adam Beneschan
+Date: Monday, February 21, 2011  7:44 PM
+
+!topic Preelaborable_Initialization inconsistency?
+!reference 10.2.1(11.3/2)
+!from Adam Beneschan 11-02-21
+!discussion
+
+I realize this is kind of late for anything to be done to Ada 2012; but I note
+that AI05-236 is still listed as a "work item" on ada-auth.org, so maybe this
+should be thrown into this AI if it's simple to fix (if a fix is needed)...
+
+I'm trying to figure out whether this example is intended to be legal:
+
+    generic
+        type Index_Type is range <>;
+    package Gen_Pack is
+        pragma Preelaborate;
+        C : constant Index_Type := Index_Type'First;
+
+        type T1 is tagged private;
+        pragma Preelaborable_Initialization (T1);
+    private
+        type T1 is tagged record
+            X : Index_Type := Index_Type'First;  --(A)
+        end record;
+    end Gen_Pack;
+
+My understanding is that the declaration of C is legal, even though the package
+is declared with Preelaborate and C's initial expression is a nonstatic
+expression, since the elaboration of the generic specification doesn't actually
+evaluate anything.  (An instance of Gen_Pack may be illegal depending on the
+actual type for Index_Type, but that's not my concern here.)
+
+I'm less clear on line (A), though.  For the Preelaborable_Initialization pragma
+to be legal, the full view has to have preelaborable initialization, which means
+that the components all have to have preelaborable initialization.
+10.2.1(11.3/2) says that a component with a default expression has preelaborable
+initialization if the expression's execution doesn't perform any actions
+prohibited in preelaborable constructs.
+
+This is where I'm getting hung up, because to me the expression's execution
+*does* perform an operation that's prohibited in preelaborable constructs, i.e.
+evaluating a nonstatic expression Index_Type'First.  The way I interpret the
+rules, C's initial expression is also prohibited in preelaborable constructs,
+but that doesn't make C illegal because C isn't actually elaborated.  But the
+way 10.2.1(11.3/2) is worded, the fact that nothing is elaborated doesn't
+matter.
+
+I'm guessing that this isn't the intent; i.e. that in a generic package
+specification, X is legal just as C is (but that X could make the
+Preelaborable_Initialization pragma illegal in a particular instance of the
+generic).  I'm not sure the wording is adequate to reflect this intent, though.
+(If others agree that the wording needs clarification, this could be a case
+where a To Be Honest paragraph in the AARM is sufficient.)
+
+But I'd still like confirmation from someone that the above source is supposed
+to be legal, because I'm looking into a bug report that involves this.  (No, I'm
+not making a last-minute push to find errors in the RM before the deadline.
+This one arises from a real issue.)
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Monday, February 28, 2011  12:43 AM
+
+...
+> I realize this is kind of late for anything to be done to Ada 2012;
+> but I note that AI05-236 is still listed as a "work item" on
+> ada-auth.org, so maybe this should be thrown into this AI if it's
+> simple to fix (if a fix is needed)...
+
+Well, as usual your timing is perfect (NOT): the ARG meeting ended the day
+before you sent this.
+
+We essentially decided that it wasn't worth fixing the problem noted in
+AI05-0236-1. The only preelaborable things that shouldn't generate code are
+listed in C.4, and these aren't (we think) incompatible with the bizarre cases
+in AI05-0236-1. (We also noted that a fix would be incompatible.)
+
+But...
+
+> I'm trying to figure out whether this example is intended to be legal:
+>
+>     generic
+>         type Index_Type is range <>;
+>     package Gen_Pack is
+>         pragma Preelaborate;
+>         C : constant Index_Type := Index_Type'First;
+>
+>         type T1 is tagged private;
+>         pragma Preelaborable_Initialization (T1);
+>     private
+>         type T1 is tagged record
+>             X : Index_Type := Index_Type'First;  --(A)
+>         end record;
+>     end Gen_Pack;
+>
+> My understanding is that the declaration of C is legal, even though
+> the package is declared with Preelaborate and C's initial expression
+> is a nonstatic expression, since the elaboration of the generic
+> specification doesn't actually evaluate anything.  (An instance of
+> Gen_Pack may be illegal depending on the actual type for Index_Type,
+> but that's not my concern here.)
+
+Right, although this is a language bug that isn't worth fixing, not a "feature".
+
+> I'm less clear on line (A), though.  For the
+> Preelaborable_Initialization pragma to be legal, the full view has to
+> have preelaborable initialization, which means that the components all
+> have to have preelaborable initialization.  10.2.1(11.3/2) says that a
+> component with a default expression has preelaborable initialization
+> if the expression's execution doesn't perform any actions prohibited
+> in preelaborable constructs.
+
+I don't see this. This is identical to the expression in the original
+AI05-0236-1 question (and the reason that C is legal). The problem is that
+Index_Type'First is not the name of an object (it is a value), so none of the
+rules of 10.2.1(5-9/2) are violated. So there is no illegality here.
+
+Worse, I don't see any reason that this is true in an instance, either, no
+matter what the actual type is.
+
+That's bad, because this subtype would be lying about the
+"preelaborable_initialization" property in an instance with a dynamic actual for
+Index_Type. OTOH, again there is no guarantee about no code being generated for
+such types (as described in C.4), so there is no formal problem with this.
+
+...
+> I'm guessing that this isn't the intent;
+
+Please don't guess about the intent; there is no intent here other than that we
+don't want to mess with this problem at all. :-)
+
+...
+> But I'd still like confirmation from someone that the above source is
+> supposed to be legal, because I'm looking into a bug report that
+> involves this.  (No, I'm not making a last-minute push to find errors
+> in the RM before the deadline.  This one arises from a real issue.)
+
+Nice to hear that your customers find RM corner cases just like you do. :-)
+
+The ARG adopted the following resolution at the end of the recent meeting:
+
+"Thanks to Adam Beneschan for providing problems whose complexity is in inverse
+proportion to their importance."
+
+[I suspect that you have been getting "credit" for some questions that you
+didn't raise...but some of the "best" ones definitely are yours - particularly
+AI05-0115-1.]
+
+I admit that there are times that I'm glad that you don't come to ARG meetings.
+I suspect that putting you and Steve Baird in the same room would cause
+quadratic multiplying of bizarre language cases to the point that the heads of
+some ARG members would explode! ;-)
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Tuesday, March 15, 2011  4:37 PM
+
+> I'm happy with saying, "Sorry, that message came in too late, if it's
+> a real bug, maybe we'll fix it for Ada 2020."
+
+That's a possibility.
+
+> You've been pounding your shoe on the table about keeping to the Ada
+> 2012 schedule, and dealing with every little thing doesn't help with
+> that.  ;-)
+
+True, but in this case, we decided not to deal with the bug (ever), and Adam has
+shown another interesting consequence of that (preelaborable_initialization is a
+lie) that we hadn't considered. I'm not sure that there is a real problem
+(everything is self consistent, just meaningless), but I wanted someone to think
+about it before we round-filed the problem.
+
+If we think we *do* need a fix, then we probably should take this entire AI off
+the table now, in order to keep to the schedule (the original AI also was too
+late in that it wasn't opened until after the June 2010 deadline, so we're under
+no obligation to fix it now). But of course as a bug, we don't want to lose it
+completely.
+
+****************************************************************
+
+From: Bob Duff
+Date: Wednesday, March 16, 2011  4:58 PM
+
+OK, I read the message in question, and decided that it's in the same category
+as the other stuff in this AI -- the rules are kind of messed up, but there's no
+actual problem that NEEDS to be fixed.  I've included a new version of
+
+    AI05-0236-1, Additional Problem with preelaborated generics
+
+below, written as a !confirmation.  [This is version /02 of the AI - Editor.]
+Randy, I suggest you include the email mentioned above in the !appendix, so it
+doesn't get lost, but we take no further action on these issues.
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent