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

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

--- ai05s/ai05-0005-1.txt	2006/12/30 05:01:28	1.3
+++ ai05s/ai05-0005-1.txt	2007/01/13 05:25:56	1.4
@@ -55,3 +55,94 @@
 
 ****************************************************************
 
+From: Pascal Leroy
+Sent: Wednesday, January 3, 2007   1:39 PM
+
+I am looking at the example in 3.10.1(2.a-2.d), and specifically at the
+first comment in 3.10.1(2.d).
+
+I surely hope that this comment is incorrect, otherwise adding "with P" in
+front of the body of P would change the semantics.  Surely we did not
+design a language where withing yourself has any observable effect...
+
+I actually think that this comment is just inconsistent with the rules:
+even if you are in the scope of a nonlimited_with_clause for P,
+3.10.1(2.4/2) doesn't apply because the completion of T is not declared in
+a visible part.
+
+I am not exactly sure how the example should be modified.  Perhaps it
+should say "note that the second rule ensures that a
+nonlimited_with_clause for P doesn't make Ptr.all'Size legal before the
+completion of T".
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, January 3, 2007  12:20 PM
+
+> I actually think that this comment is just inconsistent with the rules:
+> even if you are in the scope of a nonlimited_with_clause for P,
+> 3.10.1(2.4/2) doesn't apply because the completion of T is not declared in
+> a visible part.
+
+Yes, that's obviously true.
+ 
+> I am not exactly sure how the example should be modified.  Perhaps it
+> should say "note that the second rule ensures that a
+> nonlimited_with_clause for P doesn't make Ptr.all'Size legal before the
+> completion of T".
+
+I think the entire part after the comma should be dropped. I don't think anything useful
+can be said for this example. The sentence is nonsense in any case, because we know
+that "with P.C" is the same as "with P, P.C;". This is just the example of why
+we need the "in whose visible part", and it hardly makes sense to mention the
+other case (it would be a very different example).
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Thursday, January 4, 2007   9:44 AM
+
+Another one to put in this AI: 4.1(7/2) has apparently been changed by the
+Amendment (otherwise it wouldn't say /2, right?) but it has no
+cross-reference to an AI.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, January 4, 2007   12:27 PM
+
+This is one of the changes from AI05-0004; the tools didn't support such
+cross-references when those were put in. That needs to be done, and the version
+really ought to be /3 on those (see AI95-0004 for a complete list).
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, January 12, 2007   6:53 PM
+
+The reason behind the first half of 10.2.1(15.3/2) is very obscure, the AARM Reason
+note should explain:
+
+Such an allocator would provide a backdoor way to get a global variable into a pure
+unit, so it is prohibited. Most such allocators are illegal anyway, as their type is
+required to have Storage_Size = 0. But access parameters and access discriminants
+don't necessarily disallow allocators. However, a call is also illegal here
+(by the preelaboration rules), so access parameters cannot cause trouble. So this
+rule is really about prohibiting allocators in discriminant constraints:
+
+    type Rec (Acc : access Integer) is record
+        C : Character;
+    end record;
+
+    Not_Const : constant Rec (Acc => new Integer'(2)); -- Illegal.
+
+The second half of the rule is needed because aggregates can specify the default
+initialization of a private type or extension using <> or the ancestor subtype
+of an extension aggregate. The subtype of a component could use an allocator to
+initialize an access discriminant; the type still could have a
+pragma Preelaborable_Initialization given. Ada 95 did not allow such private types
+to have preelaborable initialization, so such a default initialization could not
+have occurred. Thus this rule is not incompatible with Ada 95.
+
+****************************************************************

Questions? Ask the ACAA Technical Agent