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

--- ai05s/ai05-0029-1.txt	2006/11/14 01:19:20	1.1
+++ ai05s/ai05-0029-1.txt	2007/04/05 01:49:14	1.2
@@ -1,4 +1,4 @@
-!standard 12.5(8)                                       06-11-13    AI05-0029-1/01
+!standard 12.5(8)                                       07-04-04    AI05-0029-1/02
 !class binding interpretation 06-11-13
 !status work item 06-11-13
 !status received 06-06-02
@@ -8,7 +8,8 @@
 !subject Meaning of 12.5(8)
 !summary
 
-TBD.
+Some operators and primitive subprograms may not be declared at all but still exist,
+and they can be named and called from generic instantiations in some cases.
 
 !question
 
@@ -61,10 +62,120 @@
 
 !wording
 
-TBD.
+Change 7.3.1(3/1) as follows:
 
+For a composite type, the characteristics (see 7.3) of the type are determined
+in part by the characteristics of its component types. At the place where the
+composite type is declared, the only characteristics of component types used
+are those characteristics visible at that place. If later immediately within the
+declarative region in which the composite type is declared additional characteristics
+become visible for a component type, then any corresponding characteristics become
+visible for the composite type. Any additional predefined operators are implicitly
+declared at that place. {If there is no such place, then additional predefined
+operators are not declared at all, but they still exist.}
+
+AARM Note: We say that they exist because they can emerge in some unusual generic
+instantiations. See 12.5(8/2).
+
+Change 7.3.1(6/1) as follows:
+
+Inherited primitive subprograms follow a different rule. For a derived_type_definition,
+each inherited primitive subprogram is implicitly declared at the earliest place,
+if any, immediately within the declarative region in which the type_declaration occurs,
+but after the type_declaration, where the corresponding declaration from the parent is
+visible. If there is no such place, then the inherited subprogram is not declared at
+all{, but it still exists. For a tagged type, it is possible to dispatch to an} [An]
+inherited subprogram that is not declared at all[ cannot be named in a call and cannot
+be overridden, but for a tagged type, it is possible to dispatch to it].
+
+Editor's Note: We remove the part about not being able to name it or call it, because
+you can do just that in some cases involving generic instantiations and emergence.
+
+Change 12.5(8/2) as follows:
+
+The formal type also belongs to each category that contains the determined category. The
+primitive subprograms of the type are as for any type in the determined category. For a
+formal type other than a formal derived type, these are the predefined operators of the
+type. For an elementary formal type, the predefined operators are implicitly declared
+immediately after the declaration of the formal type. For a composite formal type, the
+predefined operators are implicitly declared either immediately after the declaration
+of the formal type, or later immediately within the declarative region in which the
+type is declared according to the rules of 7.3.1. In an instance, the copy of such
+an implicit declaration declares a view of the predefined operator of the actual
+type, even if this operator has been overridden for the actual type {or even if it
+is never declared for the actual type}. The rules specific to formal derived types
+are given in 12.5.1.
+
+AARM Note: The somewhat cryptic phrase "even if it is never declared" is intended
+to deal with the following oddity: 
+
+package Q is
+    type T is limited private;
+private
+    type T is range 1 .. 10;
+end Q;
+
+generic
+    type A is array (Positive range <>) of T;
+package Q.G is
+    A1, A2 : A (1 .. 1);
+private
+    B : Boolean := A1 = A2;
+end Q.G;
+
+with Q.G;
+package R is
+    type C is array (Positive range <>) of Q.T;
+
+    package I is new Q.G (C); -- Where is the predefined "=" for C?
+end R;
+
+An "=" is available for the formal type A in the private part of Q.G.  However, no "="
+operator is ever declared for type C, because its component type Q.T is limited.  Still,
+in the instance I the name "=" declares a view of the "=" for C which
+exists-but-is-never-declared.
+
+End of AARM Note.
+
+Change 12.5.1(21/2) as follows:
+
+For a formal derived type, the predefined operators and inherited user-defined
+subprograms are determined by the ancestor type and any progenitor types, and
+are implicitly declared at the earliest place, if any, immediately within the
+declarative region in which the formal type is declared, where the corresponding
+primitive subprogram of the ancestor or progenitor is visible (see 7.3.1).
+In an instance, the copy of such an implicit declaration declares a view of the
+corresponding primitive subprogram of the ancestor or progenitor of the formal
+derived type, even if this primitive has been overridden for the actual type
+{or even if it is never declared for the actual type}. When the ancestor or
+progenitor of the formal derived type is itself a formal type, the copy of
+the implicit declaration declares a view of the corresponding copied operation
+of the ancestor or progenitor. In the case of a formal private extension, however,
+the tag of the formal type is that of the actual type, so if the tag in a call
+is statically determined to be that of the formal type, the body executed will
+be that corresponding to the actual type.
+
 !discussion
 
+We cannot make the call to "=" illegal because it could be in the generic body,
+and that would be a contract model violation.
+
+We cannot say that the rules of 7.3.1 do not apply to 12.5(8) because this very
+issue was discussed long ago as part of DR 8652/0037, and it clear that we
+intended the language to work that way (we want package private types and generic
+formal private types to be as similar as possible).
+
+So we have to come up with a model that explains where the missing "=" operator
+comes from. In 7.3.1 we already have the notion of subprograms that exist but
+are never declared. This shows up in the context of dispatching, because we need
+to specify what body gets executed when dispatching would land in a subprogram
+that was not declared. This seems to be a firm foundation to build upon, so we
+say that in the example at hand the generic makes it possible to name a subprogram
+that exists but was never declared. This requires two changes in chapter 12 (for
+operators of composite formal types and for primitive subprograms of formal
+derived types). And it requires changes in 7.3.1 to explain that the operators exist
+but are not declared. No normative change is required for derived types in 7.3.1,
+but there is bracketed text that it telling lies, so it seems good to fix it.
 
 --!corrigendum A.18.2(239/2)