CVS difference for ais/ai-00402.txt

Differences between 1.1 and version 1.2
Log of other versions for file ais/ai-00402.txt

--- ais/ai-00402.txt	2005/01/27 23:23:29	1.1
+++ ais/ai-00402.txt	2005/01/28 02:10:51	1.2
@@ -1,4 +1,4 @@
-!standard 03.07(10)                                    05-01-22 AI95-00402/01
+!standard 03.07(10)                                  05-01-22   AI95-00402/01
 !standard 06.05(20)
 !class amendment 05-01-27
 !status work item 05-01-27
@@ -269,4 +269,141 @@
 
 !appendix
 
+From: Tucker Taft
+Sent: Sunday, January 23, 2005  1:33 PM
+
+Pascal and others expressed concern about the proposed
+rule that access discriminants for nonlimited types
+would have the accessibility of the enclosing *type*,
+while access discriminants for limited types would
+have the accessiblity of the enclosing *object*.
+
+After some discussion, we concluded that we wanted
+the nonlimited ones to adopt the current rule
+for limited ones if at all possible.  Together
+we determined that about the only way to make this
+work was to disallow defaults for access discriminants
+when used on a nonlimited type.  I volunteered to
+write up an AI on this topic.  And here it is. [Editor's note: this
+is version /01.]
+
+[For what it is worth, I went off on a tangent worrying
+about components whose access discriminants are
+initialized by allocators of an anonymous type
+(Steve loves those!).  After inventing various complicated
+rules to deal with them, I discovered that they
+aren't a problem after all, because the subtype
+indication of a component is elaborated when the
+enclosing *type* is elaborated, rather than when
+the enclosing object is created.  So they end
+up with a "safe" accessibility level after all,
+and all instances of the type designate the
+same allocated object via this component's
+access discriminant, and all is copacetic.]
+
+I presume we'll discuss this in the shadow
+of the Eiffel tower...
+
 ****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, January 24, 2005  9:27 PM
+
+> AARM Language Design Philosophy note:
+
+I got a good laugh out of this one. Usually, we try to use existing
+categories. I suppose you meant "Language Design Principles" (or
+"MetaRules", as it's known in the AARM source).
+
+> Modify the paragraph added after 6.5(20) by AI-354:
+
+I think you mean AI-344. I don't think "Group execution-time budgets" have
+anything to do with accessibility checks!
+
+What I don't understand about this is why there isn't any problem on
+assignment of these guys. You went into a length explanation of why variant
+record components aren't a problem, but (a) I don't understand why variants
+would have anything to do with it; (b) why this isn't a problem on top-level
+discriminants. There isn't any accessibility check defined for components of
+any kind, after all; and there certainly isn't any defined for record types.
+So what prevents:
+
+    type Rec(Acc_Disc : access Integer) is null record;
+
+    Global_Rec : Rec (...);
+
+    procedure P is
+       I : aliased Integer := ...;
+       Local_Rec : Rec (I'Access);
+    begin
+       Global_Rec := Local_Rec;
+    end P;
+
+Ah, got it; the *discriminant check* prevents problems. The AI really,
+really ought to show an example like this and make this point. Talking about
+discriminant defaults hardly makes the appropriate connection (probably
+because they are such a lousy way to define mutual records - sigh). We
+shouldn't have to write examples each time to figure out what is going on...
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, January 25, 2005  10:57 AM
+
+>>AARM Language Design Philosophy note:
+>
+>
+> I got a good laugh out of this one. Usually, we try to use existing
+> categories. I suppose you meant "Language Design Principles" (or
+> "MetaRules", as it's known in the AARM source).
+
+Yes, that is what I meant.
+
+>
+>
+>>Modify the paragraph added after 6.5(20) by AI-354:
+>
+>
+> I think you mean AI-344. I don't think "Group execution-time budgets" have
+> anything to do with accessibility checks!
+
+Details, details...
+
+>
+> What I don't understand about this is why there isn't any problem on
+> assignment of these guys. You went into a length explanation of why variant
+> record components aren't a problem, but (a) I don't understand why variants
+> would have anything to do with it; (b) why this isn't a problem on top-level
+> discriminants. There isn't any accessibility check defined for components of
+> any kind, after all; and there certainly isn't any defined for record types.
+> So what prevents:
+>
+>     type Rec(Acc_Disc : access Integer) is null record;
+>
+>     Global_Rec : Rec (...);
+>
+>     procedure P is
+>        I : aliased Integer := ...;
+>        Local_Rec : Rec (I'Access);
+>     begin
+>        Global_Rec := Local_Rec;
+>     end P;
+>
+> Ah, got it; the *discriminant check* prevents problems. The AI really,
+> really ought to show an example like this and make this point. Talking about
+> discriminant defaults hardly makes the appropriate connection (probably
+> because they are such a lousy way to define mutual records - sigh).
+
+It made the connection for me, but you are probably right,
+not everyone has that particular synapse wired very tightly.
+In any case, the whole point of disallowing defaults is
+to disallow changing the discriminant as a result of
+an assignment statement.
+
+> ... We
+> shouldn't have to write examples each time to figure out what is going on...
+
+Agreed.
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent