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

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

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?

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

From: Pascal Leroy
Date: Wednesday, November 19, 2008  9:00 AM

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

I think that 12.5(8/2) (in particular the fifth sentence) answers this.
(And the answer is yes.)

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

From: Adam Beneschan
Date: Wednesday, November 19, 2008  9:33 AM

> (On a very old question from Adam.)

This is now AI05-0110, by the way.
 
...
> I think that 12.5(8/2) (in particular the fifth sentence) answers this.
>  (And the answer is yes.)

I don't think the fifth sentence of 12.5(8/2) applies. This sentence talks
about "predefined operators". "Predefined operator" is a very specific term
that refers to certain subprograms (see 6.6(1)), and describes where they
are implicitly declared. The example I gave didn't involve any operators.
It was more about the looser concepts of "operations" and "characteristics"
of a type; my example involved assignment and the "null" literal, neither
of which is an operator, and neither of which has an implicit declaration.

I suppose you could argue that what this sentence in 12.5(8/2) says about
operators should apply by analogy to other characteristics, but not without
a certain amount of hand-waving. (I still am not certain how much
hand-waving is acceptable in the RM/ISO Standard; I seem at times to be
a lot more bothered by it than others.  :-))

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

From: Pascal Leroy
Date: Wednesday, November 19, 2008  11:47 AM

I think you're right.  The best fix would probably be to talk about
"additional characteristics" in 12.5.1(20/2-21/2), although I have never
been too happy with this "characteristics" stuff, which is nowhere defined.
I wonder if it would be better to talk about "categories": if the categories
to which the parent type belongs change, the derived type belongs to the same
categories.

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

From: Randy Brukardt
Date: Wednesday, November 19, 2008  1:37 PM

That wouldn't work, because a component is considered a "characteristic",
but it surely doesn't have anything to do with "category" of a type. These
are both defined terms, after all. The characteristics of a type are
(loosely) defined in 7.3(16/2), and it is much broader than just a category.
(I see a tiny buglet in 7.3(16/2): it should say "classes and categories",
because as written, "categories" that aren't classes aren't included, and
that could lead something to think that limitedness (for example) is not a
characteristic.)

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

From: Randy Brukardt
Date: Thursday, November 20, 2008  6:41 PM

> (I see a tiny buglet in 7.3(16/2): it should say "classes and 
> categories", because as written, "categories" that aren't classes 
> aren't included, and that could lead something to think that 
> limitedness (for example) is not a
> characteristic.)

This was wrong; characteristics are all about inheritance, but categories
that aren't classes aren't inherited. They're not interesting here since
that they're always given on the full declaration (or even the partial view
in some cases); there's no issue about becoming visible at a later point.
So it makes sense that these are not characteristics.

(That makes Pascal's comment about "categories" even more wrong, not that
"more wrong" matters much.)

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