CVS difference for ai05s/ai05-0232-1.txt
--- ai05s/ai05-0232-1.txt 2010/10/26 03:22:17 1.1
+++ ai05s/ai05-0232-1.txt 2011/01/20 06:23:00 1.2
@@ -1,13 +1,13 @@
-!standard 7.6(17.1/3) 10-10-25 AI05-0232-1/00
-!class binding interpretation 10-10-25
+!standard 7.6(17.1/3) 11-01-20 AI05-0232-1/01
+!class confirmation 11-01-20
!status work item 10-10-25
!status received 10-09-24
!subject Hole in AI05-0067-1
+Whether a call is required to be built-in-place is a dynamic property of the object.
@@ -28,25 +28,64 @@
limited type, and in that case we still want to have the result
built in place, with no copying.
-Is a fix needed? (Yes.)
+Is a fix needed? (No.)
+The existing wording is correct.
+RM 7.6 states:
+ When a function call or aggregate is used to initialize an object,
+ the result of the function call or aggregate is an anonymous object,
+ which is assigned into the newly-created object. For such an
+ assignment, the anonymous object might be built in place. Under
+ certain circumstances, the anonymous object is required to be built
+ in place, in which case the assignment does not involve any copying.
+ In particular:
+ If the full type of any part of the object is immutably
+ limited, the anonymous object is built in place.
+One part of any object is the object itself, so this rule implies that
+build-in-place is required if the full type of the object is immutably
+But because this wording is under "Dynamic Semantics", 3.1(7/3) does not apply
+and thus views are not involved here. For a given part, this wording refers
+to the specific nonabstract type of the part. Also note that parts other than
+the object itself cannot be class-wide (as indefinite components are not allowed);
+thus there always is a specific type.
+In the case that the object itself has a class-wide type (as opposed to a
+specific tagged type), this wording refers to the type identified by the tag
+of the part. [One could imagine that we ought to have a "To Be Honest" note to
+cover this unlikely case - although if we do that, we need to classify this
+as a ramification - Randy.]
+This is what distinguishes this situation from the related question addressed in
+AI05-0099-1, where explicit wording changes such as "If the full type of the object
+is a tagged type, and the tag of the object identifies a controlled type.",
+[Not quite sure I buy this; that wording originally seemed to imply a compile-time
+determination of the type -- it said "is of", not just "is" -- while this
+wording is clearly runtime. Even so, this seems to be a horribly weak argument.
+We decided in AI05-0099-1 that there is no implicit "dynamic type" for an object,
+so to assume one here is uncomfortable. It would be better to bite the bullet
+and add explicit words like the above to the 7.6(17.1/3) rule. - Randy.]
+In the case of a function returning Some_Limited_Interface_Type'Class,
+build-in-place is required if and only if the specific nonabstract type of the
+function result is immutably limited.
+This means that for two different elaborations of the object declaration given
+in the question, one call to Some_Function might require build-in-place while the
+other might not.
-Probably functions returning limited interfaces ought to be built-in-place. But
-I'm not sure how to word that. (Can this happen for components of a result? For
-an aggregate? I don't think so...)
-[Editor's comments: Note that I can't quite imagine how to chose the return
-convention of a function at runtime, so I think it is fine to require
-limited classwide interfaces to be built-in-place; they can only be
-used as if they are limited even if the actual type is non-limited, so
-the problems with real assignments don't come up.]
!topic Possible hole in AI05-0067?
Questions? Ask the ACAA Technical Agent