CVS difference for ai05s/ai05-0139-2.txt

--- ai05s/ai05-0139-2.txt	2010/10/26 00:21:22	1.9
+++ ai05s/ai05-0139-2.txt	2011/02/08 08:21:06	1.10
@@ -3965,6 +3965,45 @@
 ****************************************************************
 
 From: Tucker Taft
+Sent: Monday, June 14, 2010  7:33 AM
+
+> ...
+>>> I think the reason you have this rule is so that indexing works on
+>>> objects of T'Class: that requires dispatching and that means that
+>>> the tag slot can't change for the indexing functions.
+>> That isn't really necessary, since even if the derived type happens
+>> to name a different function for indexing, the ancestor's ones will
+>> still exist.
+>
+> True, but it means that for
+>
+>     type T is tagged ... with Variable_Indexing => F1;
+>     type NT is new T with private with Variable_Indexing => F2.
+>
+>     S : NT;
+>     C : T'Class := T'Class(S);
+>
+> C(1) would call F1(C, 1) while S(1) would call F2(S, 1). That seems
+> confusing at best, since the objects have the same tag and value.
+> We've tried hard to avoid this sort of effect for regular dispatching,
+> I would think we'd want to do that here, too.
+
+We seem to have switched sides on this one!
+
+You had convinced me that if the user
+chooses to do this, it seems well-defined and not something we should
+necessarily try to prevent.  You pointed out that there are contract model
+issues with trying to enforce a rule like this, so it just didn't seem important
+enough.
+
+Making a type indexable is a pretty big deal, and it seems unlikely that you
+would do something like the above by "mistake."  So there seems no reason to try
+to prevent it just to be "friendly."  Compilers could provide warnings, I
+suppose, though I doubt it is worth their effort.
+
+****************************************************************
+
+From: Tucker Taft
 Sent: Monday, October 25, 2010  10:17 AM
 
 Here is the update to AI05-0139, based on the minutes. [This is version /07