!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 !qualifier Clarification !priority Medium !difficulty Medium !subject Inheritance of components of generic formal derived types !summary 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? Consider: package Parent is type Message is new String; type Message_Rec is tagged private; private type Message_Rec is tagged record The_Length : natural := 0; The_Content : Message (1 .. 60); end record; end Parent; generic type Message_Type is new Message_Rec with private; package Parent.Child is procedure Copy (From_The_Word : in Message; To_The_Message : in out Message_Type); end Parent.Child; package body Parent.Child is procedure Copy (From_The_Word : in Message; To_The_Message : in out Message_Type) is begin To_The_Message.The_Content -- Legal? (Yes.) (1 .. From_The_Word'length) := From_The_Word; end Copy; end Parent.Child; 7.3.1(4) clearly indicates that it applies only to a type declared by a derived_type_declaration, but a generic formal derived type is not such a 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 (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. 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. !ACATS test The first issue occurs in ACATS test CA11018. No additional test is needed. The second issue appears to have no example showing a difference. !appendix !from Randy Brukardt !date April 27, 2000 A petition against CA11018 has led to the discussion of a possible language hole. Here is the question: Test CA11018 has the following declarations (where irrelevant constructs have been removed): package CA11018_0 is type Message is new String; type Message_Rec is tagged private; private type Message_Rec is tagged record The_Length : natural := 0; The_Content : Message (1 .. 60); end record; end CA11018_0; generic type Message_Type is new Message_Rec with private; package CA11018_0.CA11018_2 is procedure Copy (From_The_Word : in Message; To_The_Message : in out Message_Type); end CA11018_0.CA11018_2; package body CA11018_0.CA11018_2 is procedure Copy (From_The_Word : in Message; To_The_Message : in out Message_Type) is begin To_The_Message.The_Content -- Legal? (1 .. From_The_Word'length) := From_The_Word; end Copy; end CA11018_0.CA11018_2; We do not believe that the component The_Content is visible in the body of the generic CA11018_0.CA11018_2. Obviously the author of the test expected that the components of the parent type, Message_Rec, would become visible when entering the private part of the child unit CA11018_0.CA11018_2, as explained in RM95 7.3.1(3-4). Unfortunately, RM95 7.3.1(4) talks about "a type defined by a derived_type_definition", and in this case Message_Type is not defined by a derived_type_definition, it is defined by a formal_derived_type_definition. Therefore, RM95 7.3.1(4) does not apply, and no additional characteristics of Message_Rec become visible when entering the private part (or the body) of the generic child. ----- The discussion of the petition raised the following points: I noted that 12.5.1(21) echos the language of 7.3.1(3-4), but uses "subprograms" rather than "characteristics", so it doesn't apply to components. Another expert commented that AI-43's summary seems to apply to this case, but that neither the discussion nor the corrigendum wording suggests that derived types were considered. A third expert pointed out that 12.5.1(20) says that components are inherited "as for a derived_type_definition". He felt this clearly meant that 7.3.1(4)'s rules were invoked. While some respondents thought this was conclusive, others felt that the connection was tenuous at best. They requested an AI. The primary argument that there is a gap is that 12.5.1(20) (and 3.4) define _what_ components are inherited. But they don't define _where_ these components become visible. That is done by 7.3.1(4). As an aside, I wonder why 12.5.1(20-21) do not simply invoke 7.3.1(3-4) for the characteristics of generic formal derived types, rather than defining a bunch of new text. The AARM does not point out any problems with having those rules 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. *************************************************************