Version 1.2 of ai05s/ai05-0110-1.txt

!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... ;-)

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

From: Adam Beneschan
Date: Friday, August 8, 2008  10:12 AM

> 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.

Hmmm... that's not how interpret it.  7.3.1(3/1) talks about composite
types and seems to apply mostly to things like arrays of private
types:

    type T1 is private;
    type T2 is array (natural range <>) of T1;

I don't think this rule applies to my code snippet, and I didn't intend
for it to.  What the RM appears to be saying in 7.3.1(4/1) is, "There is a
rule about derived types that looks just like 7.3.1(3/1) except that,
in essence, you replace 'composite types whose component type is private'
with 'derived types whose parent type is private'".
Or, actually, replace "composite" with "derived" and "component type"
with "parent type". So 7.3.1(4/1) doesn't really have anything to do with
composite types. If 7.3.1(4/1) were written without the "corresponding rule"
shorthand, I suppose it would look like:

"For a derived type, the characteristics (see 7.3) of the type are determined
in part by the characteristics of its parent type. At the place where the
derived type is declared, the only characteristics of parent types used
are those characteristics visible at that place. If later immediately
within the declarative region in which the derived type is declared within
the immediate scope of the derived type additional characteristics become
visible for the parent type, then any corresponding characteristics become
visible for the derived type. Any additional predefined operators are
implicitly declared at that place."

Maybe it should have been just been done that way---it would have been more
verbose but perhaps less confusing.

The point of my original question was: does this also apply to generic formal
derived types?

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