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

Differences between 1.1 and version 1.2
Log of other versions for file ai05s/ai05-0161-1.txt

--- ai05s/ai05-0161-1.txt	2009/07/11 03:06:22	1.1
+++ ai05s/ai05-0161-1.txt	2009/10/17 01:53:15	1.2
@@ -1,4 +1,6 @@
-!standard  H.4(23)                                 09-07-08    AI05-0161-1/01
+!standard  13.12.1(4/2)                                 09-07-25    AI05-0161-1/02
+!standard  13.13.2(40/2)
+!standard  13.13.2(52/2)
 !class Amendment 09-07-08
 !status work item 09-07-08
 !status received 09-06-14
@@ -8,41 +10,100 @@
 
 !summary
 
-The following restrictions identifiers exist:
+The following restrictions identifier exist:
 
     No_Default_Elementary_Stream_Attributes
 
 !problem
 
-For elementary types, the representation in terms of stream elements is
-implementation defined.  The only way to ensure interoperability of streams
-between different implementations is by having user-defined stream attributes
-for all data exchanged. However, it is easy to inadvertantly use a stream
-operation for a type that has no user-defined stream attributes, or for a
-composite type with such a subcomponent.
+Streams can be used to reliably interchange data between programs that
+need not be compiled with the same implementation, or with programs
+written in other programming languages.
+
+However, the stream representation of elementary types is
+implementation defined.  In order to ensure portability, it is
+necessary to make sure that the stream attributes of all elementary
+types involved are user-defined. This restriction makes sure that it
+is not possible to use (directly or through composition) a stream
+attribute whose specification has been inadvertantly omitted.
 
-The proposed restriction would make sure that no default implementation of
-stream attributes for elementary types is used.
-
 !proposal
 
 (See wording.)
 
 !wording
+
+Add after 13.12.1(4/2):
+
+No_Default_Stream_Attributes
+   The default implementation of
+   stream-oriented attributes for elementary types is never available.
+
+Replace 13.13.2(40/2) with:
 
-Add after H.4(23):
+T is nonlimited and no pragma Restriction
+(No_Default_Stream_Attributes) applies to the partition.
 
-No_Default_Elementary_Stream_Attributes
+Add to 13.13.2(52/2), after "a limited type ... attributes":
 
-    There is no use of default stream attributes for elementary types.
+An elementary type which is not an access type supports supports
+external streaming, unless a pragma restriction
+(No_Default_Stream_Attributes) applies to the partition and no Read
+and Write attributes are available.
 
 !discussion
 
-We cannot forbid all default stream attributes, since the default attributes for
-composite types are defined to compose from their elements, which does not raise
-an issue. However, if a composite type has a subcomponent of an elementary type
-for which their is no user-defined stream attribute, it would be considered a
-"use" of the default elementary type stream attribute, and therefore forbidden.
+This proposal builds upon the notion of availability of
+stream-oriented attributes because it seemed the simplest way to make
+sure that the composition rules work properly. This is basically what
+happens with limited types. With this approach, we could even decide
+that the pragma needs not be partition-wide, since the default
+implementation still exists (it is just not available where the pragma
+applies).
+
+The restriction is purposedly limited to elementary types. There is no
+reason to restrict composite types, where proper behaviour is ensured
+by the composition rules, as soon as all component types are
+available. However, this does not show in the restriction name; should
+it be No_Default_Elementary_Stream_Attributes, or even
+No_Default_Elementary_Type_Stream_Attributes? Looks like a mouthfull.
+
+The rule applies to all stream-oriented attributes, therefore
+including S'Stream_Size. It does not seem to make sense to access
+S'Stream_Size if the corresponding S'Read and S'Write are not available.
+
+There is an issue with generic formal types. In the body of a generic
+(to which the restriction applies), the usual assume-the-worst rule
+would forbid the use of any stream-oriented attribute of a formal
+elementary type (including in the implicit implementation of a
+stream-oriented attribute with a subcomponent of such a type). This
+problem did not arise for limited types, since being limited is part
+of the contract. Some possibilities are:
+
+- Accept the fact. For direct use of a stream attribute of a formal
+  elementary type, there is an escape, since the user can call the
+  attribute through a renaming declared in the specification of the
+  package (including the private part with the usual boilerplate). For
+  the subcomponent case, the composite type itself should be declared
+  in the specification (which can drag a lot of other stuff to the
+  specification), with similar renamings of stream attributes. This
+  trick would not be possible for generic subprograms (no big deal in
+  my view), and puts all the burden on the user.
+
+- Introduce some strange rule that the attribute is available in the
+  generic body if there is something (like a renaming) that requires
+  its availability in the specification.
+
+- Introduce a pragma Require_Stream_Availability(S), to be given in the
+  formal part.
+
+- Make the check a post-compilation rule. Isn't it what 13.12(8.2/1)
+  is about?
+
+- Choose a different approach, and rather than making the default
+  attributes non-available, change the default implementation to
+  raising Program_Error. But a restriction is intended to check things
+  at compile-time... 
 
 !example
 
@@ -59,7 +120,44 @@
 Editor's note:
 
 The original proposal for this restriction did not suggest where it would be
-added to the Standard. I rather arbitraryly picked H.4(23).
+added to the Standard. I rather arbitraryly picked H.4(23). [That was version /01
+of this AI.]
 
 ****************************************************************
 
+From: Jean-Pierre Rosen
+Sent: Thursday, July 23, 2009  3:41 PM
+
+Attached is my homework from Brest. [This is version /02 of the AI - ED]
+
+I thought it was simple until I considered generics (sigh).
+There are some open issues in the !discussion section; opinions welcome.
+
+While looking at this section, it made me think of a related question:
+what is the value of S'Stream_Size if it is not user-specified, while S'Write
+has been user-specified?  13.13.2(1.6/2) does not say that it corresponds to
+the default implementation. It seems that S'Stream_Size is intended to be used
+to specify a size while using the default implementation of S'Write, but that
+the other way round is not defined.
+Is it worth another AI?
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, October 15, 2009  8:08 PM
+
+I don't see any problem. 13.13.2(1.6/2) says nothing about Read or Write.
+The "minimum number of stream elements required by the first subtype" is
+well-defined no matter how those attributes are defined. Stream_Size is of
+course used in the default Read and Write attributes, but obviously does not
+have any effect on user-defined attributes. Moreover, Stream_Size could be
+useful in contexts other than the attributes (such as determining the
+appropriate size for an Unchecked_Conversion to stream elements), so I think
+this is a good thing.
+
+I suppose one could have a user note saying that "Stream_Size is meaningless
+for user-defined Read and Write attributes", but that seems obvious and clearly
+follows from the definition. It seems more like something to mention in textbooks
+and tutorials to me. So I don't think we need to do anything (and surely not an AI).
+
+****************************************************************

Questions? Ask the ACAA Technical Agent