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

--- ai05s/ai05-0052-1.txt	2008/05/22 05:22:45	1.8
+++ ai05s/ai05-0052-1.txt	2008/05/24 03:39:52	1.9
@@ -1,4 +1,4 @@
-!standard 4.8(5.3/2)                               08-05-21    AI05-0052-1/07
+!standard 4.8(5.3/2)                                  08-05-23    AI05-0052-1/08
 !standard 7.5(8)
 !class binding interpretation 07-05-15
 !status ARG Approved  7-0-1  08-02-09
@@ -118,7 +118,8 @@
 
     *  An explicitly limited record type;
 
-    *  A non-formal tagged limited private type;
+    *  A non-formal limited private type that is tagged or has
+       at least one access discriminant with a default_expression;
 
     *  A task type, a protected type, or a synchronized
        interface;
@@ -142,8 +143,8 @@
 formal part of the generic unit.
 
 AARM Ramification: In an instance, a type is descended from the actual type
-corresponding to the formal, and all rules are rechecked. Bodies are
-excepted so that we assume the worst there; the complex wording is
+corresponding to the formal, and all rules are rechecked in the specification.
+Bodies are excepted so that we assume the worst there; the complex wording is
 required to handle children of generics and unrelated bodies properly.
 
 !discussion
@@ -247,6 +248,15 @@
 after an intermably long discussion as the best choice of literally dozens that
 were proposed.
 
+As part of that definition, we allow limited private types with access discriminants
+with defaults to be immutably limited. We did that because the full type must
+be immutably limited (by 3.7(10/2) or especially the rewritten version of AI-63).
+We could have just patched 3.7(10) (which inexplicably changed in the Amendment to
+exclude limited private types, which is a glaring unintentional incompatibility with
+Ada 95), but that would mean that some things that are legal could be made illegal
+simply by converting the type into a private type. That would be sending exactly
+the wrong message - we want people to use private types as much as possible.
+
 
 For the second question, we note that the new rule would need to be checked in the
 private part of an instance, and 4.8(5.3/2) already has such wording.
@@ -299,17 +309,19 @@
 @dinss
 A type is @i<immutably limited> if it is one of the following:
 
-@xbullet<A descendant of an explicitly limited record type;>
+@xbullet<An explicitly limited record type;>
 
-@xbullet<A descendant of a non-formal tagged limited private type;>
+@xbullet<A non-formal limited private type that is tagged or has
+at least one access discriminant with a @fa<default_expression>;>
 
-@xbullet<A descendant of a task type, a protected type, or a synchronized interface;>
+@xbullet<A task type, a protected type, or a synchronized interface;>
 
-@xbullet<A descendant of a formal limited private type, except within the body of a
-generic unit or a body declared within the declarative region of a generic unit,
-if the type is declared within the formal part of the generic unit;>
+@xbullet<A descendant of an immutably limited type.>
 
-@xbullet<A type with a part that is of an immutably limited type.>
+A descendant of a generic formal limited private type is presumed
+to be immutably limited except within the body of a generic unit
+or a body declared within the declarative region of a generic unit,
+if the type is declared within the formal part of the generic unit.
 
 
 !ACATS test
@@ -813,5 +825,104 @@
 So I think that we're OK here.
 
 I've updated the AI with these changes (excepting Tucker's action item).
+
+Tucker Taft:
+
+...
+> This last paragraph doesn't work right. It's missing the generic body 
+> exception, for one thing.
+
+Ummm..., doesn't it say "Within the *declaration* of a generic unit..."?
+
+ > ...It should only be presumed to be immutably limited
+> in the specification of a generic unit, not in the body; and it needs 
+> to take children into account.
+
+I thought it was more straightforward to say where it was legal rather
+than to say where it was illegal. But you are probably right that it
+should be legal in the declaration of a child, presuming it gets
+rechecked in the instance of the child. That begins to get complicated
+enough that perhaps we should revert to the tried-and-true wording that
+excludes the body, rather than includes the spec.
+
+> ...
+> (We know that this last wording is the in the right order for generic 
+> bodies, because we use variants of it in a number of other rules; 
+> inventing new wording is likely to be error-prone, especially for 
+> cases this complex.)
+
+Fair enough.
+ 
+
+> ...
+> However, there's a problem: 3.7(10) allows access discriminants in 
+> private types so long as the full type is immutably limited; that got 
+> lost in Ada 2005's 3.7(10/2), and 3.7(10/3) just copies that. Tucker 
+> has an action item to see if that needs a fix. Not sure whether that 
+> fix needs to be in the definition of immutably limited or just in 
+> 3.7(10/3). If just 3.7(10/3) is changed, then there is a possibility 
+> of an Ada 95 incompatibility -- but that wouldn't be fixed by including parts anyway.
+
+In looking at this right now, I believe a fix is needed.
+I see two alternatives:
+
+    1) In 7.5 say that a limited private (untagged) type is immutably
+       limited if it has an access discriminant with a default.
+       Since we recheck 3.7 in the private part, we will make
+       sure the full type is also immutably limited.
+
+    2) In 3.7 say that a limited private (untagged) type may have
+       a default expression for an access discriminant, even
+       though it is not considered "immutably limited."
+
+I tend to favor (1), even though it is somewhat of a self-fulfilling prophecy,
+because it is more flexible for the user.
+
+
+> Still, pending resolution of that issue, there doesn't seem to be any 
+> reason to change this rule to include parts. Ada 95 didn't allow them, 
+> so there is unlikely to be an issue.
+> ...
+> I've updated the AI with these changes (excepting Tucker's action item).
+
+Can I consider the above my action item?
+
+Randy Brukardt:
+
+> In looking at this right now, I believe a fix is needed.
+> I see two alternatives:
+> 
+>     1) In 7.5 say that a limited private (untagged) type is immutably
+>        limited if it has an access discriminant with a default.
+>        Since we recheck 3.7 in the private part, we will make
+>        sure the full type is also immutably limited.
+> 
+>     2) In 3.7 say that a limited private (untagged) type may have
+>        a default expression for an access discriminant, even
+>        though it is not considered "immutably limited."
+> 
+> I tend to favor (1), even though it is somewhat of a self-fulfilling 
+> prophecy, because it is more flexible for the user.
+
+Humm. My first thought was yuck, but then I had to conclude that it probably
+is OK - as you say, the full type will have to be an immutably limited type,
+so there is no privacy breakage. (It's kinda a backdoor way to declare that,
+but its compatible, while anything more explicit would be incompatible). And it
+eliminates a potential landmine, particularly for the new AI-52 rule: an
+allocator for a coextension of a non-private immutably limited type would
+work, but restructure to use a private type and your coextension allocator
+is illegal. That is exactly the wrong structuring message to send.
+
+> > Still, pending resolution of that issue, there doesn't seem to be 
+> > any reason to change this rule to include parts. Ada 95 didn't allow 
+> > them, so there is unlikely to be an issue.
+> > ...
+> > I've updated the AI with these changes (excepting Tucker's action item).
+> 
+> Can I consider the above my action item?
+
+Well, originally you needed a new AI to accomplish the above. However, since
+Pascal has forced us to withdraw various AIs anyway, we might as well stick
+the repair in AI-52. In which case I guess I can do your work for you.
 
 ****************************************************************