CVS difference for ai12s/ai12-0030-1.txt

Differences between 1.1 and version 1.2
Log of other versions for file ai12s/ai12-0030-1.txt

--- ai12s/ai12-0030-1.txt	2012/06/07 01:36:26	1.1
+++ ai12s/ai12-0030-1.txt	2012/06/29 04:33:45	1.2
@@ -1,13 +1,14 @@
-!standard 12.5.1(20/3)                               12-06-06    AI12-0030-1/01
+!standard 12.5.1(20/3)                               12-06-28    AI12-0030-1/02
 !class binding interpretation 12-06-06
 !status work item 12-06-06
 !status received 12-05-11
 !priority Low
 !difficulty Medium
-!subject Formal derived types and attribute availability
+!subject Formal derived types and stream attribute availability
 !summary
 
-**TBD.
+Stream attributes are inherited like primitive operations of an untagged
+formal derived type.
 
 !question
 
@@ -45,59 +46,64 @@
 Is the use of Flim'Read legal? Should it be?
 If it is legal, are the dynamic semantics well defined?
 
-Assuming that attribute availability is a "characteristic", it seems that
+Assuming that stream attribute availability is a "characteristic", it seems that
 12.5.1(20/3) applies and the use within the generic body is legal. This means we
 need to define the meaning of the corresponding construct in the instance.
 
 The "even if it is never declared" wording in 12.5.1(21/3) handles a similar
 case, the case where a generic formal type promises a primitive operation that
-the corresponding actual type lacks. Do may need to add some analogous wording
-to handle this case? (***???***).
+the corresponding actual type lacks. Do we need to add some analogous wording
+to handle this case? (No.).
 
-!recommendation
+!reponse
 
-** TBD.
+Stream attributes act like predefined primitive operations in most contexts,
+so they should act that way in this example as well.
 
 !wording
 
-** TBD.
+Add after AARM 12.5.1(21.a/3):
 
+AARM To Be Honest: The availability of stream attributes is not formally a
+characteristic of a type; but it is still determined by the
+ancestor type for a formal derived type in the same way as the the
+characteristics are. Similarly, while stream attributes are not formally
+primitive operations of a type, the implementation of a stream attribute that
+is executed for a call of an attribute of a formal derived type is determined in
+the same way as the subprogram body that is executed for a primitive subprogram
+of a formal derived type.
+
 !discussion
 
 The answer to the legality question is clear: characteristics of all sorts
 come from the ancestor type, not the actual type, so of course the attribute
 is legal and it will call the attribute of the ancestor type.
 
-What's not so clear is how to get this result. "Availability of stream
-attributes" is not a characteristic of a type (at least it is not listed
-in 3.4, which is the definition of a "characteristic". So the existing rules
-don't cover this case. There seem to a number of possibilities:
-
-(1) Just add a TBH noting that "availability" of stream attributes is
-treated in the same way as a characteristic of the type. It's very rare to
-see a derived untagged formal type, as such types can only match derived
-untagged types -- which is very limited, especially given that untagged
-derivations themselves aren't that common (it's usually better to declare
-a new type).
-
-If we go this route, this AI should be written as a Ramification.
-
-(2) Add "availability of stream attributes" to the list of characteristics
-found in 3.4 (probably with a new bullet at 3.4(15)). Then then existing
-rule 12.5.1(20/3) and various rules in 7.3.1 would handle this case without
-further changes. However, there is a risk that this would then interfere with
-the availability definitions in 13.13.2; most likely those would need to be
-modified. [I didn't check this or determine if there would be any compatibility
-problems with this approach - Editor]
-
-(3) Add a new rule after 12.5.1(20/3) specifically to say that "availability
-of stream attributes" is the same as that of the ancestor type, and the stream
-attribute called is that of the ancestor type. This is the safest solution,
-but it probably requires the most wording.
+However, the wording of the Standard is definitely not clear on this point.
+"Availability of stream attributes" is not a characteristic of a type (at least
+it is not listed in 3.4, which is the definition of a "characteristic". So the
+existing rules don't cover this case.
+
+We could try to define "availability" as a "characteristic" (by adding a new
+bullet at 3.4(15), but that most likely would lead to conflicts as 7.3.1 defines
+how characteristics are inherited for private types, while 13.13.2 does so for
+"availability". These are similar, but probably not precisely the same, and we'd
+have to reword 13.13.2 in order to avoid confusion.
+
+Alternatively, we could just throw some text and add a new rule after
+12.5.1(20/3) specifically to say that "availability of stream attributes" is the
+same as that of the ancestor type, and the stream attribute called is that of
+the ancestor type. But that just adds a lot of text to say something obvious.
+
+It's rare to see a derived untagged formal type, as such types can only match
+derived untagged types -- which is very limiting, especially given that untagged
+derivations themselves aren't that common (it's usually better to declare a new
+type). As such, it's not critical to have the Standard wording perfect in this
+area. So we simply add a To Be Honest note so there is no doubt of the intent.
 
 !ACATS test
 
-** TBD.
+An ACATS C-test could be written that is similar to the example in the question.
 
 !appendix
 

Questions? Ask the ACAA Technical Agent