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

--- ai05s/ai05-0192-1.txt	2009/11/04 05:02:50	1.1
+++ ai05s/ai05-0192-1.txt	2009/11/04 06:26:38	1.2
@@ -11,7 +11,7 @@
 
 !summary
 
-The result of 'Input is constrained if the type is composite and the 
+The result of 'Input is constrained if the type is composite and the
 first subtype is constrained.
 
 !question
@@ -86,7 +86,8 @@
 From: Steve Baird
 Sent: Monday, May 11, 2009  4:04 PM
 
-A question was raised at AdaCore about the Input attribute of an untagged derived type with a constrained first subtype, as in
+A question was raised at AdaCore about the Input attribute of an untagged
+derived type with a constrained first subtype, as in
 
     type T1 (D : Natural) is ... ;
     type T2 is new T1 (123);
@@ -97,17 +98,20 @@
    In the above example, should Constraint_Error be raised if the
    discriminant value read from the stream is not equal to 123?
 
-The RM appears to contradict itself with respect to the definition of the result subtype of T2'Input.
+The RM appears to contradict itself with respect to the definition of the result
+subtype of T2'Input.
 
-The more specific (and therefore presumably correct) applicable passage is 13.13.2(50/2), which says
+The more specific (and therefore presumably correct) applicable passage is
+13.13.2(50/2), which says
 
      In the parameter_and_result_profiles for the stream-oriented
      attributes, the subtype of the Item parameter is the base subtype of
      T if T is a scalar type, and the first subtype otherwise. The same
      rule applies to the result of the Input attribute.
 
-This suggests that the result subtype is constrained and that therefore Constraint_Error should be raised. Note that the changes
-AI05-007 makes in this area have no effect in the non-scalar case.
+This suggests that the result subtype is constrained and that therefore
+Constraint_Error should be raised. Note that the changes AI05-007 makes in this
+area have no effect in the non-scalar case.
 
 The opposing argument is based on the following chain:
     13.13.2(25/2): "For an untagged derived type, the Output
@@ -123,7 +127,8 @@
       above for the first subtype of the derived type) to that of the
       given subtype."
 
-This suggests that the result subtype is unconstrained. I think an AARM note resolving this apparent contradiction is all that is needed.
+This suggests that the result subtype is unconstrained. I think an AARM note
+resolving this apparent contradiction is all that is needed.
 
 Question #2:
    Assuming that Constraint_Error is to be raised, is an implementation
@@ -162,32 +167,40 @@
 <   Assuming that Constraint_Error is to be raised, is an implementation
 <   required, allowed, or forbidden to perform the constraint
 <   check as soon as the discriminant value is read from the stream?
-<   Would it be legal to defer the check until the end, ... ? 
+<   Would it be legal to defer the check until the end, ... ?
 
-I would say that 13.13.2(36/2) seems to provide the answer to this question. It states; "It is unspecified at which point and in which order these checks are  performed. In particular, if Constraint_Error is raised due to the  failure of one of these chec
ks, it is unspecified how many stream  elements have been read from the stream."
+I would say that 13.13.2(36/2) seems to provide the answer to this question. It
+states; "It is unspecified at which point and in which order these checks are
+performed. In particular, if Constraint_Error is raised due to the failure of
+one of these checks, it is unspecified how many stream  elements have been read
+from the stream."
 
-As to the first question, I would think people would expect the constraint error to be raised.
+As to the first question, I would think people would expect the constraint error
+to be raised.
 
 ****************************************************************
 
 From: Steve Baird
 Sent: Wednesday, May 13, 2009  5:36 PM
 
-> I would say that 13.13.2(36/2) seems to provide the answer to this 
-> question. It states; "It is unspecified at which point and in which 
-> order these checks are  performed. In particular, if Constraint_Error 
-> is raised due to the  failure of one of these checks, it is 
+> I would say that 13.13.2(36/2) seems to provide the answer to this
+> question. It states; "It is unspecified at which point and in which
+> order these checks are  performed. In particular, if Constraint_Error
+> is raised due to the  failure of one of these checks, it is
 > unspecified how many stream  elements have been read from the stream."
 
 I tend to agree with you.
-The question here is whether the freedom you described extends across a call boundary. In 13.1(15.2/2), presumably the phrase "in the same way" means that 3.4(27/2) defines the dynamic semantics of a call to
+The question here is whether the freedom you described extends across a call
+boundary. In 13.1(15.2/2), presumably the phrase "in the same way" means that
+3.4(27/2) defines the dynamic semantics of a call to
 
    My_Untagged_Derived_Type'Inherited_Streaming_Attribute.
 
-> As to the first question, I would think people would expect the 
+> As to the first question, I would think people would expect the
 > constraint error to be raised.
 
 Again, I agree with you.
-I still think there is enough of an apparent contradiction to justify an AARM note.
+I still think there is enough of an apparent contradiction to justify an AARM
+note.
 
 ****************************************************************