CVS difference for 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