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

--- ai05s/ai05-0139-2.txt	2010/06/13 00:59:17	1.7
+++ ai05s/ai05-0139-2.txt	2010/06/14 01:07:39	1.8
@@ -3839,3 +3839,113 @@
 
 ****************************************************************
 
+From: Tucker Taft
+Sent: Sunday, June 13, 2010  11:53 AM
+
+>> OK folks, this is a doozy.
+>
+> You are right about that! A few comments noticed while posting this AI:
+>
+> In 4.1.6, you say "The aspects may not be overridden, but the
+> functions they denote may be." I assume this is intended to be a
+> Legality Rule (it's in introductory text, so I'm not sure how it is enforced).
+
+Probably unnecessary.  Your point about generic contract model seems to pretty
+well sink it anyway.
+
+> 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.
+
+> However, this appears to be a generic contract model problem. We don't
+> know whether or not these aspects were used when deriving from a
+> generic formal, so it's not clear how the following works:
+>
+>     generic
+>        type T is tagged private;
+>     package Gen is
+>        type NT is new T with private with
+>            Variable_Indexing => Vfoo,
+>            Constant_Indexing => Cfoo;
+>        -- Assume definitions of Vfoo and Cfoo here.
+>     end Gen;
+>
+> Is this specification legal? If Gen is instantiated with a type that
+> has indexing already (such as Ada.Containers.Vectors), is the instance illegal?
+> Etc.
+
+Let's drop the rule.
+
+>
+> ---
+>
+> You've defined an indexable type as a user-defined tagged type with
+> the aspects specified. Are we allowing these to be specified on
+> abstract types and interfaces? Those are user-defined tagged types. I
+> can see reasons for allowing that, but we then have to be careful that
+> we don't call abstract routines. (That also adds additional cases to
+> the generic above.)
+
+I would presume you want to allow them on abstract types, so yes, we need to be
+careful not to allow calls on an abstract subprogram.  Of course, the
+"equivalence" rules should take care of it... ;-)
+
+>
+> ---
+>
+> And why do you say "user-defined" in the indexable type definition?
+> That seems to imply that the containers cannot be indexable, because
+> they are defined by us, not the user. Clearly that is not what you
+> meant, but why do we care who defined the type??
+
+We talk about user-defined assignment and finalization, even though we use those
+features in language-defined packages.  It is "user-defined" as opposed to
+"predefined" operations.  "User- defined" elsewhere in the manual means "not
+predefined" (see 3.2.3, for example) so I think it is OK to use that here as
+well.
+
+> ---
+>
+> 5.5.1:
+>
+> I'm not a fan of  "A /(reversible) iterator object/ is an object of a
+> (reversible) iterator type." I was initially confused as to why you
+> didn't define a "forward iterator object". But I eventually realized
+> that you were being cute and are actually defining two terms with one
+> sentence. I suppose the index will help a bit, but I suspect that many
+> readers looking up "iterator object" will fail to see the definition here.
+
+I think some of the definitions can be
+eliminated.  I put in more definitions
+than I actually used.
+>
+> ---
+>
+> The legality rules for an iterable type seem to make the intended
+> definition for Maps conflict with the rules for a default iterator.
+> Specifically, I was expecting that we would define two pairs of
+> indexing functions: one for cursors and the other for the key type, so
+> that AI_Author_Map ("Taft") := 139; would be legal. But these rules only allow one index function.
+> Shouldn't the rules be more flexible than that? Probably they should
+> require the existence of an indexable function with the right profile,
+> but allow the existence of others.
+
+You can define two pairs of indexing functions, but only one of the pairs can be
+the "default" indexing functions.  I can see that the wording is confusing.
+Constant_Indexing can denote multiple functions, but only one of them can have
+the additional requirements specified for an iteratable type's default constant
+indexing function.
+
+Perhaps the Legality Rules should be worded more as
+follows:
+
+    Of the functions denoted by the Constant_Indexing
+    aspect (if any) of an iteratable type, exactly
+    one shall have the following properties:
+
+
+****************************************************************
+