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

Differences between 1.3 and version 1.4
Log of other versions for file ai05s/ai05-0192-1.txt

--- ai05s/ai05-0192-1.txt	2010/01/09 01:31:30	1.3
+++ ai05s/ai05-0192-1.txt	2011/03/11 06:59:05	1.4
@@ -1,12 +1,15 @@
-!standard 13.1(15.2/2)                                 09-11-03  AI05-0192-1/01
-!standard 13.13.2(36/2)
+!standard 13.1(15.2/2)                                 11-03-11  AI05-0192-1/02
+!standard 13.13.2(8.1/2)
+!standard 13.13.2(25/2)
 !standard 13.13.2(50/2)
-!class ramification 09-11-03
+!class binding interpretation 11-02-20
+!status Amendment 2012 11-03-11
+!status ARG Approved  8-0-0  10-02-20
 !status work item 09-11-03
 !status received 09-05-11
 !priority Low
 !difficulty Easy
-!qualifier Omission
+!qualifier Error
 !subject Behavior of 'Input for types with constrained first subtypes
 
 !summary
@@ -23,7 +26,7 @@
 
     X : T1 := T1 (T2'Input (...));
 
-Is the result of T2'Input constrained? If so, it must raise
+Is the result subtype of T2'Input constrained? (Yes.) If so, it must raise
 Constraint_Error is the discriminant is not 123.
 
 13.13.2(50/2) says that it is, but 13.13.2(25/2) says that
@@ -41,32 +44,68 @@
 
 (See summary.)
 
+!wording
+
+Modify 13.13.2(8.1/2):
+
+For an untagged derived type, the Write (resp. Read) attribute is inherited
+according to the rules given in 13.1 if the attribute is {Redundant[specified
+and] }available for the parent type at the point where T is declared. For a
+tagged derived type, these attributes are not inherited, but rather the
+default implementations are used.
+
+Modify 13.13.2(25/2):
+
+For an untagged derived type, the Output (resp. Input) attribute is
+inherited according to the rules given in 13.1 if the attribute is
+{Redundant[specified and]} available for the parent type at the point where
+T is declared. For a tagged derived type, these attributes are not inherited,
+but rather the default implementations are used. 
+
+Modify 13.13.2(50/2):
+
+In the parameter_and_result_profiles for {the default implementations of} 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.
+
+AARM Discussion: An inherited stream attribute has a profile as determined by
+the rules for inheriting primitive subprograms (see 13.1 and 3.4).
+
+
 !discussion
 
-In researching this question, your editor looked at the reason 13.1(15.2/2)
-exists. AI95-00444-1 says that it was added to "specify the parameter types"
-of inherited attributes. Why this is needed is not clear; 13.13.2(50/2)
-defines appropriate types.
-
-I was told to write a ramification, but given that this contradicts an intentional
-ARG decision, I think that is inappropriate. It seems to me that the rule
-13.1(15.2/2) is just plain wrong, and needs to be changed. The reason is that
-if the attribute is available but the fact that it is inherited isn't visible
-(as could happen for a private type/full view combination), we might end up with
-different constraints on the attribute depending on its view (even though the
-implementation cannot vary by view). That can't possibly be good.
-
-But I'm not sure if there would be some problems if the rule at 13.1(15.2/2)
-was dropped. Would the inherited subprogram assume the wrong constraints?
-
-So it is important to find out whether Pascal, Tucker, and Randy were insane
-at the time of AI95-00444-1. I recommend that we simply give this AI back to
-Steve Baird to do the needed research.
+13.1(15.2/2) says that inherited aspects of a derived type work the same way
+as a user-defined primitive subprogram of the type. It should be obvious that
+they have to work this way, as the body of the subprogram will be expecting the
+constraints it was defined with, not some other constraints.
+
+13.13.2(50/2) was intended to apply to new stream aspects but not inherited
+ones. That means it applies to all tagged types and most other types as well.
+We add some wording to make that clear. Also note that we never inherit the
+the default implementation of the attributes; we only inherit when the attribute
+is specified.
+
+With this new wording, the answer to the first question is easy: the subtype
+is constrained. But we get a different answer if we have an explicitly specified
+attribute:
 
+    type T1 (D : Natural) is ... 
+       with Input => ...;
 
+    type T2 is new T1 (123);
+
+    X : T1 := T1 (T2'Input (...));
+
+Now the aspect is inherited, and the subtype of T2'Input is unconstrained. Note
+that it is possible to inherit operations that could not have been written explicitly
+-- but this is the way inherited subprograms work and we couldn't change it if
+we wanted to.
+
+
 On the second question, 13.13.2(36/2) applies, and is very clear. It says "at
 which point" the checks are made is unspecified. So long as the exception raised
-by the checks is handled by the proper handler (which is required by the imfamous
+by the checks is handled by the proper handler (which is required by the infamous
 11.6), the implementation is correct.
 
 One could argue that the wording of 13.13.2(36/2) is so vague that almost anything
@@ -76,6 +115,36 @@
 
 We could add an AARM note to the effect that we meant what we said, but that seems
 silly.
+
+!corrigendum 13.13.2(8.1/2)
+
+@drepl
+For an untagged derived type, the Write (resp. Read) attribute is inherited
+according to the rules given in 13.1 if the attribute is available for the
+parent type at the point where @i<T> is declared. For a tagged derived type,
+these attributes are not inherited, but rather the default implementations
+are used.
+@dby
+For an untagged derived type, the Write (resp. Read) attribute is inherited
+according to the rules given in 13.1 if the attribute is specified and
+available for the parent type at the point where @i<T> is declared. For
+a tagged derived type, these attributes are not inherited, but rather the
+default implementations are used.
+
+!corrigendum 13.13.2(25/2)
+
+@drepl
+For an untagged derived type, the Output (resp. Input) attribute is inherited
+according to the rules given in 13.1 if the attribute is available for the
+parent type at the point where @i<T> is declared. For a tagged derived type,
+these attributes are not inherited, but rather the default implementations
+are used.
+@dby
+For an untagged derived type, the Output (resp. Input) attribute is inherited
+according to the rules given in 13.1 if the attribute is specified and
+available for the parent type at the point where @i<T> is declared. For a
+tagged derived type, these attributes are not inherited, but rather the
+default implementations are used.
 
 
 !ACATS Test

Questions? Ask the ACAA Technical Agent