Version 1.1 of ais/ai-00233.txt

Unformatted version of ais/ai-00233.txt version 1.1
Other versions for file ais/ai-00233.txt

!standard 12.05.1 (20)          00-04-27 AI95-00233/00
!class binding interpretation 00-04-27
!status work item 00-04-27
!status received 00-04-27
!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).
!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.)
!recommendation
(See summary.)
!wording
( I dunno. I'd make this a !confirmation myself. )
!discussion
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).
!corrigendum xx.xx.xx(0x)
!ACATS test
This issue occurs in ACATS test CA11018. No additional test is needed.
!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.

*************************************************************

Questions? Ask the ACAA Technical Agent