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

--- ai05s/ai05-0158-1.txt	2010/06/13 05:10:50	1.7
+++ ai05s/ai05-0158-1.txt	2010/06/14 01:24:50	1.8
@@ -1426,3 +1426,82 @@
 
 ****************************************************************
 
+From: Tucker Taft
+Date: Tuesday, May 18, 2010  9:59 PM
+
+By the way, with all this talk about the resolution rule for membership tests, I
+wonder whether we have it right currently:
+
+RM 4.5.2(3/2) says:
+
+     The tested type of a membership test is the
+     type of the range or the type determined by
+     the subtype_mark. If the tested type is tagged,
+     then the simple_expression shall resolve to be
+     of a type that {is convertible (see 4.6) to}
+     [covers or is covered by] the tested type;
+     if untagged, the expected type for the
+     simple_expression is the tested type.
+
+The "{}" and the "[]" show the changes made to accommodate membership tests for
+interface types. We now seem to allow the following:
+
+    type T1 is tagged ...
+    type T2 is new T1 with ...
+
+    X : T1;
+    Y : T2;
+
+    if Y in T1 then ...
+
+That was not permitted before this change.  You would have had to write:
+
+    if Y in T1'Class then ...
+
+or
+
+    if T2'Class(Y) in T1 then ...
+
+That is, one or the other needed to be classwide, if they weren't the same type.
+I think we want to preserve that requirement.  The "convertible" rule allows
+conversion between specific types, so long as the target type is an ancestor.
+
+[Aside: I think allowing conversion to an ancestor specific type when there are
+private extensions involved is a bug in the language, since it allows the
+bypassing of a private type's primitive operations. Allowing conversion to a
+classwide type doesn't create any such problems.  For what that's worth...]
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Tuesday, May 18, 2010  10:29 PM
+
+Are we allowing:
+
+   O1 : T'Class;
+   O2 : T;
+   O3 : NT; -- NT is derived from T
+
+   if O1 in O2 | O3 then
+
+??
+
+If not, this would differ from the similar conditional expression. If so, the
+complexity of resolution is up another level...
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Tuesday, May 18, 2010  10:32 PM
+
+...
+> That is, one or the other needed to be classwide, if they weren't the
+> same type. I think we want to preserve that requirement.
+
+Probably best done with a legality rule. Resolution should be as non-specific as
+possible. (I want it to be a *lot* more non-specific in this case, requiring the
+tested type to be determinable without any context or reference to the
+expression. But that's a separate discussion.)
+
+****************************************************************
+