Version 1.2 of ai05s/ai05-0161-1.txt

Unformatted version of ai05s/ai05-0161-1.txt version 1.2
Other versions for file ai05s/ai05-0161-1.txt

!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
!priority Medium
!difficulty Medium
!subject Restrictions for default stream attributes of elementary types
!summary
The following restrictions identifier exist:
No_Default_Elementary_Stream_Attributes
!problem
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.
!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:
T is nonlimited and no pragma Restriction (No_Default_Stream_Attributes) applies to the partition.
Add to 13.13.2(52/2), after "a limited type ... attributes":
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
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
--!corrigendum H.4(23)
!ACATS test
B-Tests should be constructed to verify that this restriction is enforced.
!appendix

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). [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