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

--- ai12s/ai12-0030-1.txt	2013/01/04 04:38:04	1.5
+++ ai12s/ai12-0030-1.txt	2013/07/16 22:42:46	1.6
@@ -1,4 +1,4 @@
-!standard 12.5.1(20/3)                               12-07-15    AI12-0030-1/03
+!standard 12.5.1(20/3)                               13-06-15    AI12-0030-1/04
 !standard 13.13.2(49/2)
 !class binding interpretation 12-07-15
 !status work item 12-06-06
@@ -8,8 +8,9 @@
 !subject Formal derived types and stream attribute availability
 !summary
 
-Stream attributes are inherited like primitive operations of an untagged
-formal derived type.
+For an untagged formal derived type, stream attributes (at runtime, in an
+instance) are those of the actual type. Those of the ancestor type do not
+reemerge.
 
 !question
 
@@ -41,11 +42,13 @@
    begin
       Lim'Read (S, Lim_Var);
       Dlim'Read (S, Dlim_Var); -- Illegal.
-      I;
+      I; -- Legal, but raises Program_Error when called.
+
    end;
 
-Is the use of Flim'Read legal? Should it be?
-If it is legal, are the dynamic semantics well defined?
+Is the use of Flim'Read legal? (Yes.) Should it be? (Yes.)
+If it is legal, are the dynamic semantics well defined? (Yes; when
+the procedure I invokes Dlim'Read, Program_Error is raised).
 
 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
@@ -54,7 +57,9 @@
 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 we need to add some analogous wording
-to handle this case? (No.).
+to handle this case? (No, but wording is added to ensure that the dynamic
+behavior of streaming attributes is defined in all cases including, for
+example, a task type with no user-defined streaming operations).
 
 !recommendation