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

--- ai05s/ai05-0007-1.txt	2006/03/23 03:30:57	1.2
+++ ai05s/ai05-0007-1.txt	2006/11/13 23:47:09	1.3
@@ -1,4 +1,4 @@
-!standard 13.13.2(50/2)                                 06-03-17    AI05-0007-1/01
+!standard 13.13.2(50/2)                              06-11-12    AI05-0007-1/02
 !standard 13.13.2(51/2)
 !class binding interpretation 06-03-17
 !status work item 06-03-17
@@ -33,19 +33,41 @@
 
 !recommendation
 
-Relax the requirement for the base subtype.
+Relax the requirement for the base subtype.  Allow the first subtype
+rather than the base subtype as the formal parameter type in the
+specified attribute subprogram.
 
 !wording
 
-(TBD.)
+Modify 13.13.2(51/2) as follows:
 
-!discussion
+  For an attribute_definition_clause specifying one of these attributes, the
+  subtype of the Item parameter shall be the {first subtype or the} base subtype
+  if scalar, and the first subtype [otherwise] {if not scalar}. The same rule
+  applies to the result of the Input function.
 
-One could argue that the check is made at the location of the attribute
-definition clause. Since Lim is not scalar at that point, the 'Base
-attribute is not required.
+!discussion
 
-But this interpretation causes trouble for formal private types. Consider:
+There seems no strong reason to require the use of the base subtype in
+user-defined stream attribute subprograms. The language rule now uses the size
+of the first subtype rather than the base subtype to determine the default
+stream size, so there is no guarantee that all values of the base subtype will
+be streamable. Although the formal parameter subtype of the attribute is still
+the base subtype, there is no particular implementation burden in performing the
+first subtype constraint check when calling a user-defined subprogram that
+specifies the first subtype. Because the convention of the stream attributes is
+Intrinsic (per 6.3.1(9)), there is no danger that someone will use 'Access with
+an attribute that requires the additional constraint check. For shared
+generics there is potentially some burden in creating a wrapper for the
+stream attributes, but presumably thunks for these operations must be
+created in general if they are *not* user specified, so creating one
+when they are seems an acceptable overhead.
+
+Once we make this change, the problem with partial views disappears. Without
+this change, one could argue that the check is made at the location of the
+attribute definition clause. Since Lim is not scalar at that point, the 'Base
+attribute is not required. But this interpretation causes trouble for formal
+private types. Consider:
 
     generic
        type Lim is limited private;
@@ -55,16 +77,28 @@
        for My_Lim'Read use Read;
     end G;
 
-By the rules on legality rules in a generic instance (12.3(11)), the legality rules
-are rechecked in an instance based on the properties of the actual. Thus, if the
-instantiation is:
+By the rules on legality rules in a generic instance (12.3(11)), the legality
+rules are rechecked in an instance based on the properties of the actual. Thus,
+if the instantiation is: 
+
     package Int_G is new G (My_Lim => Integer);
+    
 the instantiation is illegal, as the attribute definition clause is illegal by
-13.13.2(51/2). This is an unnecessary limitation on the use of formal private types;
-it essentially prevents the creation of mix-in generics that define stream attributes
-for all types (as such a mix-in would not work for scalar types).
+13.13.2(51/2). This is an unnecessary limitation on the use of formal private
+types; it essentially prevents the creation of mix-in generics that define
+stream attributes for all types (as such a mix-in would not work for scalar
+types).
 
 [Humm. This seems to be a problem with Ada 95, too. Why am I not surprised? - ED]
+
+In addition to eliminating this problem with formal generic types and partial
+views, making this change will also simplify the job for the user.  An
+extremely common mistake when writing these stream attributes is to forget
+to use 'Base, which is required even for types defined as "new Integer".
+Requiring that the attribute subprograms handle 'Base rather than simply
+the first subtype seems of little value, and clearly if the user uses makes
+use of subtypes "wider" than the first subtype, they can always take care to
+use 'Base when defining the stream attributes.
 
 !ACATS test