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

Differences between 1.3 and version 1.4
Log of other versions for file ai05s/ai05-0232-1.txt

--- ai05s/ai05-0232-1.txt	2011/01/25 08:00:08	1.3
+++ ai05s/ai05-0232-1.txt	2011/01/28 02:48:37	1.4
@@ -1,5 +1,5 @@
-!standard  7.6(17.1/3)                             11-01-20    AI05-0232-1/01
-!class confirmation 11-01-20
+!standard  7.6(17.1/3)                             11-01-27    AI05-0232-1/02
+!class ramification 11-01-27
 !status work item 10-10-25
 !status received 10-09-24
 !priority Low
@@ -30,10 +30,26 @@
 
 Is a fix needed? (No.)
 
-!response
+!recommendation
 
-The existing wording is correct.
+(See summary.)
 
+!wording
+
+Add after 7.6(17.2/3):
+
+AARM To Be Honest: This is a dynamic property and is determined by the specific type of
+the parts of the actual object. In particular, if a part has a class-wide type, the
+tag of the object might need to be examined in order to determine if build-in-place
+is required. However, we expect that most Ada implementations will determine this
+property at compile-time using some assume-the-worst algorithm in order to chose
+the appropriate method to implement a given call or aggregate. In addition, there
+is no attribute or other method for a program to determine if a particular object
+has this property (or not), so there is no value to a more careful description of
+this rule. 
+
+!discussion
+
 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,
@@ -60,20 +76,7 @@
 
 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.",
-were needed.
-[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.]
+of the part.
 
 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
@@ -81,9 +84,17 @@
 
 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.
+other might not. As a practical matter, an implementation is likely to chose to
+build-in-place all objects returned from calls to Some_Function -- but this is
+not required.
 
 !ACATS Test
+
+No ACATS test is needed.
+
+!ASIS
+
+No effect on ASIS.
 
 !appendix
 

Questions? Ask the ACAA Technical Agent