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

--- ai05s/ai05-0110-1.txt	2008/10/25 04:53:14	1.2
+++ ai05s/ai05-0110-1.txt	2008/11/24 03:36:52	1.3
@@ -186,3 +186,87 @@
 
 ****************************************************************
 
+From: Pascal Leroy
+Date: Wednesday, November 19, 2008  9:00 AM
+
+> The point of my original question was: does this also apply to generic
+> formal derived types?
+
+I think that 12.5(8/2) (in particular the fifth sentence) answers this.
+(And the answer is yes.)
+
+****************************************************************
+
+From: Adam Beneschan
+Date: Wednesday, November 19, 2008  9:33 AM
+
+> (On a very old question from Adam.)
+
+This is now AI05-0110, by the way.
+ 
+...
+> I think that 12.5(8/2) (in particular the fifth sentence) answers this.
+>  (And the answer is yes.)
+
+I don't think the fifth sentence of 12.5(8/2) applies. This sentence talks
+about "predefined operators". "Predefined operator" is a very specific term
+that refers to certain subprograms (see 6.6(1)), and describes where they
+are implicitly declared. The example I gave didn't involve any operators.
+It was more about the looser concepts of "operations" and "characteristics"
+of a type; my example involved assignment and the "null" literal, neither
+of which is an operator, and neither of which has an implicit declaration.
+
+I suppose you could argue that what this sentence in 12.5(8/2) says about
+operators should apply by analogy to other characteristics, but not without
+a certain amount of hand-waving. (I still am not certain how much
+hand-waving is acceptable in the RM/ISO Standard; I seem at times to be
+a lot more bothered by it than others.  :-))
+
+****************************************************************
+
+From: Pascal Leroy
+Date: Wednesday, November 19, 2008  11:47 AM
+
+I think you're right.  The best fix would probably be to talk about
+"additional characteristics" in 12.5.1(20/2-21/2), although I have never
+been too happy with this "characteristics" stuff, which is nowhere defined.
+I wonder if it would be better to talk about "categories": if the categories
+to which the parent type belongs change, the derived type belongs to the same
+categories.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Wednesday, November 19, 2008  1:37 PM
+
+That wouldn't work, because a component is considered a "characteristic",
+but it surely doesn't have anything to do with "category" of a type. These
+are both defined terms, after all. The characteristics of a type are
+(loosely) defined in 7.3(16/2), and it is much broader than just a category.
+(I see a tiny buglet in 7.3(16/2): it should say "classes and categories",
+because as written, "categories" that aren't classes aren't included, and
+that could lead something to think that limitedness (for example) is not a
+characteristic.)
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Thursday, November 20, 2008  6:41 PM
+
+> (I see a tiny buglet in 7.3(16/2): it should say "classes and 
+> categories", because as written, "categories" that aren't classes 
+> aren't included, and that could lead something to think that 
+> limitedness (for example) is not a
+> characteristic.)
+
+This was wrong; characteristics are all about inheritance, but categories
+that aren't classes aren't inherited. They're not interesting here since
+that they're always given on the full declaration (or even the partial view
+in some cases); there's no issue about becoming visible at a later point.
+So it makes sense that these are not characteristics.
+
+(That makes Pascal's comment about "categories" even more wrong, not that
+"more wrong" matters much.)
+
+****************************************************************
+