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

--- ai05s/ai05-0232-1.txt	2011/01/20 06:23:00	1.2
+++ ai05s/ai05-0232-1.txt	2011/01/25 08:00:08	1.3
@@ -126,3 +126,84 @@
 our implementation, generating code to decide this at runtime isn't feasible.)
 
 ****************************************************************
+
+Following is the edited end of a private conversation about this AI:
+
+Randy Brukardt:
+
+Thanks. I turned this into a complete AI. But you've made me dubious 
+of the conclusion that we came to. I think we need *at least* an 
+AARM To-Be-Honest note (in which case this is a Ramification) or a 
+bit of full-blown wording (in which case it is a BI), because the 
+leap that you use to assume we use the tag doesn't make much sense.
+
+Steve Baird:
+
+Oh dear, we seem to have exchanged positions.
+
+I thought the conclusion made sense. The point is that when we are talking
+about the type of an arbitrary part of an object in a dynamic semantics check,
+and if that part happens to be tagged, we (as you explained to me) couldn't
+very well be talking about anything other than specific, nonabstract type
+associated with the part's tag.
+
+This is unchanged if the part we happen to be considering (as part of a rule
+that applies to all parts of an object) is the object itself.
+
+The object's (nominal) type might be abstract and/or classwide, but that's
+irrelevant.
+
+Randy Brukardt:
+
+The conclusion makes sense. But it doesn't match the way the standard is written.
+And I was explaining to you that you always look at the type of the parts of the
+actual returned object, not of the nominal type of the function. I had incorrectly
+convinced myself that that never required inspection of the tag (see below).
+ 
+I definitely agree that we don't care about the nominal subtype. But go back and
+read AI05-0099-1 again.
+
+It concludes:
+(1) The standard does not define a "dynamic type".
+(2) The standard always specifies when the tag needs to be consulted to determine
+    a property.
+Ergo, we needed to make a wording change for that AI.
+
+The same applies here. Yesterday, I thought that you always knew that type somewhere,
+because components cannot have class-wide types, and the types of parts are only
+(logically) consulted when the return statement is executed. For an abstract
+class-wide type as in the example, you have to be returning an object that is of
+some other specific type (so you know the type there). No tag reading needed in either
+case.
+
+But I forgot that you could also return some sort of class-wide object (either a
+stand-alone object or another function call); if that object has no inherently limited
+parts, then there is nowhere else to look; while that is unusual it is possible, and
+in those cases you'd probably need to consult the tag. If you need to consult the tag,
+we need wording (or at least a To Be Honest note).
+
+The problem that the ARG has had is that we were focusing on Adam's question. His
+question is bogus, because this is a dynamic property that doesn't necessarily get
+determined until the instant that the return statement starts returning the object.
+It is inspection of the returned object, and not anything about the properties of the
+function, that determines whether build-in-place is required. So there is no problem at
+the call site (which is what he asked): the function (and its call) has to be able to
+return a object that is build-in-place, but it only has to do that if the actual object
+requires that.
+
+But there still is a problem *inside* the function with the inspection of the returned
+object. The model is correct, but to properly use that model we need some wording --
+because there is no such thing as a dynamic type. And we all agree that we're not (only)
+looking at the nominal type of the parts of that object (the subtype is irrelevant of
+course).
+
+I think just a To Be Honest note would be sufficient, because "requires build-in-place"
+is not a property that you can query -- thus being unambiguous about the runtime value
+is not that critical. All an implementation has to do is ensure that no case that
+"requires build-in-place" is copied; it is perfectly OK to build-in-place cases that
+do not need to be handled that way. But I think we do need to mention in the standard
+that you might have to query the tag to determine this property -- or "assume-the-worse"
+about class-wide objects. That means this is a ramification and not a confirmation,
+and thus it has to be rewritten again.
+
+****************************************************************