!standard 12.5.1(21/2)                                          08-08-08  AI05-0109-1/00
!class binding interpretation 08-08-08
!status work item 08-08-08
!status received 08-05-21
!priority Low
!difficulty Hard
!qualifier Omission
!subject Characteristics of generic formal derived type are not inherited

!summary 

TBD.

!question

Consider:

    package pak1 is
       pragma elaborate_body;

       type T1 is limited private;

       generic
          type T2 is new T1;
       package pak2 is
       end pak2;

    private
       type T1 is access Integer;
    end pak1;

    package body pak1 is
       package body pak2 is
          x2 : T2 := null;   -- Legal?
       end pak2;
    end pak1;

Neither 12.5.1(20/2) nor 12.5.1(21/2) appear to cover this case.
What is the intent?

!recommendation

(See summary.)

!wording


!discussion


--!corrigendum 12.5.1(21/2)


!ACATS Test


!appendix

!topic When are characteristics of generic formal derived type available?
!reference 7.3.1(4), 12.5.1(20-21)
!from Adam Beneschan 08-05-21
!discussion

This seems to be a corner case that may involve some missing wording in the RM:

    package pak1 is
       pragma elaborate_body;

       type T1 is limited private;

       generic
          type T2 is new T1;
       package pak2 is
       end pak2;

    private
       type T1 is access Integer;
    end pak1;

    package body pak1 is
       package body pak2 is
          x2 : T2 := null;   -- Legal?
       end pak2;
    end pak1;

7.3.1(4) discusses cases where a derived type is derived from a private type;
when the appropriate substitutions are made into the language of 7.3.1(3),
it says that additional "characteristics" of a type become visible for a
derived type at a place later in the declarative region where additional
characters of the parent type become visible.

However, 7.3.1(4) refers to a derived_type_definition.  The syntax of a
formal derived type in 12.5.1(2) is a formal_derived_type_definition, so
it's not obvious that 7.3.1(4) applies to it.

12.5.1(21) does imply that for a formal derived type, if predefined operators
and user-defined subprograms of the parent type become visible later, those
operators also become visible later; thus, if the full definition of T1 were
an enumeration type, the "<" and ">" operators on T2 would be visible in the
body of pak2 (but not the spec).  Similarly, 12.5.1(20) implies that components
are inherited for a formal derived type "as for" a derived_type_definition,
which I assume includes the rules in 7.3.1(4); thus, if the full type of T1
were a record with a component F, then this component would also be visible
for type T2 in the body of pak2.

But this example doesn't involve predefined or user-defined subprograms or
components, so it's not obvious that 12.5.1(20-21) apply to this example
either.  (Neither does AI05-29.)

I think the intent is for 7.3.1(4) to apply to generic formal derived types
just as for non-generic derived types; and while 12.5.1(20-21) do make some
of those "additional characteristics" available, it doesn't work for all
characteristics.  Perhaps "or formal_derived_type_definition" just needs
to be added to 7.3.1(4).

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

From: Randy Brukardt
Date: Thursday, August 7, 2008  9:58 PM

> 7.3.1(4) discusses cases where a derived type is derived from a 
> private type; when the appropriate substitutions are made into the 
> language of 7.3.1(3), it says that additional "characteristics" of a 
> type become visible for a derived type at a place later in the 
> declarative region where additional characters of the parent type 
> become visible.

Unfortunately, this example seems to show that there is something weird
about 7.3.1(3/1) itself (which has nothing to do with generics). It talks
about the component types of composite types, and additional characteristics.
But the full type T1 is elementary! This is surely not an *additional*
charactistic, or one of a component type. It is a *different*, incompatible
characteristic!

Boiled down, the usual intepretation of this wording says that "If a
composite type and <some other stuff>, then the composite type is an
elementary type." I always thought that a type was either one or the
other (depending on its view and visibility on that view). This wording
only makes sense if it can be both at the same time.

Hopefully, someone else will take this AI when we assign it... ;-)

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