CVS difference for ais/ai-00233.txt

Differences between 1.1 and version 1.2
Log of other versions for file ais/ai-00233.txt

--- ais/ai-00233.txt	2000/04/27 23:59:20	1.1
+++ ais/ai-00233.txt	2000/10/05 02:47:30	1.2
@@ -1,4 +1,6 @@
-!standard  12.05.1    (20)                             00-04-27  AI95-00233/00
+!standard  12.05      (08)                             00-10-03  AI95-00233/01
+!standard  12.05.1    (20)
+!standard  12.05.1    (21)
 !class binding interpretation 00-04-27
 !status work item 00-04-27
 !status received 00-04-27
@@ -11,6 +13,9 @@
 Components of a generic formal derived type become visible following the rules
 of 7.3.1(4).
 
+The wording of 12.5(8/1) and 12.5.1(21/1) should be consistent with
+7.3.1(3/1-6/1).
+
 !question
 
 When, if ever, do components of a generic formal derived type become visible?
@@ -52,26 +57,114 @@
 type. Thus the rules seem to say that The_Content is not visible above. Is
 this correct? (No.)
 
+Also, Technical Corrigendum 1, the wording of 7.3.1(3-6) was changed from
+    "within the immediate scope of"
+to
+    "later immediately within the declarative region of"
+
+This change was not made in 12.5(8/1) and 12.5.1(21/1). Should it have
+been? (Yes.)
+
 !recommendation
 
 (See summary.)
 
 !wording
 
-(* I dunno. I'd make this a !confirmation myself. *)
+(See corrigendum.)
 
 !discussion
 
+12.5.1(20) says:
+
+  If the ancestor type is a composite type that is not an array type, the formal
+  type inherits components from the ancestor type (including discriminants if a
+  new discriminant_part is not specified), as for a derived type defined by a
+  derived_type_definition (see 3.4).
+
+This clearly states what components are inherited; the rules of 7.3.1(3-4)
+apply.
+
+An argument has been made that this does not define *where* the components
+become visible. However, this does not make sense; why should only part of
+rules given in 7.3.1(3-4) apply in this case? Absent any rules to the contrary
+in the standard, the only logical conclusion is that components of formal
+private and derived types are inherited and made visible as described in
+7.3.1(3-4).
+
 The ACATS test that prompted this discussion has been in use for 5 years, so
 it is clear that all compilers currently follow the recommendation.
 
-(*How to justify the recommendation*).
+In regards to the second question, it seems that the wording of 12.5(8/1) and
+12.5.1(21/1) ought to be consistent with 7.3.1, especially since both
+paragraphs reference 7.3.1.
+
+!corrigendum 12.05(08)
+
+@drepl
+The formal type also belongs to each class that contains the determined class.
+The primitive subprograms of the type are as for any type in the determined
+class. 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 in its immediate scope 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. The rules specific to formal derived types are given in 12.5.1.
+@dby
+The formal type also belongs to each class that contains the determined class.
+The primitive subprograms of the type are as for any type in the determined
+class. 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. The rules specific to formal derived types are given in 12.5.1.
+
+
+!corrigendum 12.05.01(21)
+
+@drepl
+For a formal derived type, the predefined operators and inherited user-defined
+subprograms are determined by the ancestor type, and are implicitly declared at
+the earliest place, if any, within the immediate scope of the formal type, where
+the corresponding primitive subprogram of the ancestor 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 of the formal derived type,
+even if this primitive has been overridden for the actual type. When the
+ancestor 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. 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.
+@dby
+For a formal derived type, the predefined operators and inherited user-defined
+subprograms are determined by the ancestor type, 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 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 of the formal derived type,
+even if this primitive has been overridden for the actual type. When the
+ancestor 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. 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.
 
-!corrigendum xx.xx.xx(0x)
-
 !ACATS test
+
+The first issue occurs in ACATS test CA11018. No additional test is needed.
 
-This issue occurs in ACATS test CA11018. No additional test is needed.
+The second issue appears to have no example showing a difference.
 
 !appendix
 
@@ -158,3 +251,40 @@
 apply to formal types.
 
 *************************************************************
+
+!from Randy Brukardt
+!date October 3, 2000
+
+In Technical Corrigendum 1, the wording of 7.3.1(3-6) was changed from
+    "within the immediate scope of"
+to
+    "later immediately within the declarative region of"
+
+However, 12.5(8/1) and 12.5.1(21/1) use the same wording to describe generic
+formal types. (Note that in the case of 12.5(8/1) this is the added wording.)
+Should this wording also be changed?
+
+The example given in Defect Report 8652/0019 (and in the new AARM
+7.3.1(7.v.1/1-7.v.3/1)) can't be adapted for generic formal types (because it
+depends on the separation of partial and full views, which does not happen for a
+formal type). But it seems that it would be best for the wording to be
+consistent, given that both paragraphs reference 7.3.1.
+
+(I will add this to the existing AI-233 on the same paragraphs.)
+
+			Randy Brukardt
+			ARG Editor.
+
+*************************************************************
+
+From: Bob Duff
+Date: Wednesday, October 4, 2000  7:30 AM
+
+> However, 12.5(8/1) and 12.5.1(21/1) use the same wording to describe generic
+> formal types. (Note that in the case of 12.5(8/1) this is the added
+> wording.) Should this wording also be changed?
+
+Probably.
+
+*************************************************************
+

Questions? Ask the ACAA Technical Agent