!standard 10.1.2(12/2)                               10-06-06  AI05-0122-1/01
!class binding interpretation 08-10-17
!status work item 08-10-17
!status received 08-08-22
!priority Low
!difficulty Medium
!qualifier Omission
!subject Private with and children of generics

!summary

Add a rule about children of generics as part of the rule on
what can be done with library items mentioned only in a private with.

!question

Consider the following:

generic
package Pak1 is
end Pak1;

generic
package Pak1.Pak2 is
end Pak1.Pak2;

generic
package Pak1.Pak2.Pak3 is
end Pak1.Pak2.Pak3;

with Pak1.Pak2;
private with Pak1.Pak2.Pak3;
package Pak4 is
    package New_Pak1 is new Pak1;
    package New_Pak2 is new New_Pak1.Pak2;
    package New_Pak3 is new New_Pak2.Pak3;   -- Legal?? (No.)
end Pak4;

It seems as though this ought to be illegal (since New_Pak3 doesn't occur
in a private part or body), but the wording in the Standard does not
support this. The instantiation is still within the scope of the WITH
clause for Pak1.Pak2.Pak3, since using PRIVATE on PRIVATE WITH doesn't
affect the scope of the WITH clause---it just makes certain uses to the
library unit name illegal in certain places.  Therefore 10.1.1(19) still
applies.  But nothing in 10.1.2(12-16) makes this illegal either, because
it only makes illegal certain uses of "A _name_ denoting a library item
that is visible due to being mentioned in one or more with_clauses that
include the reserved word PRIVATE"; and there is no _name_ in the body
of Pak4 that denotes Pak1.Pak2.Pak3 (New_Pak2.Pak3 certainly does not
denote this library item).

Should this be illegal? (Yes.)

!recommendation

(See Summary.)

!wording

Revise 10.1.2(12/3) (as modified by AI05-0077-1):

    A name denoting a library_item {(or the corresponding declaration for
    a child of a generic within an instance -- see 10.1.1), if it} [that]
    is visible only due to being mentioned in one or more with_clauses that
    include the reserved word private{,} shall appear only within:

!discussion

We include the wording from 10.1.1 associated with the visibility of
children of generic within instances, into the paragraph that talks about
a private with clause. An alternative was to add a rule about private
with clauses where children of generics are discussed in 10.1.1. The
approach we adopted seemed to require less additional wording.

--!corrigendum 10.1.2(xx/2)


!ACATS Test

An ACATS B-Test like the example in the question is needed.

!appendix

!topic PRIVATE WITH and generic children of generics
!reference 10.1.2(12), 10.1.1(19)
!from Adam Beneschan 08-08-22
!discussion

Is this legal?

generic
package Pak1 is
end Pak1;

generic
package Pak1.Pak2 is
end Pak1.Pak2;

generic
package Pak1.Pak2.Pak3 is
end Pak1.Pak2.Pak3;

with Pak1.Pak2;
private with Pak1.Pak2.Pak3;
package Pak4 is
    package New_Pak1 is new Pak1;
    package New_Pak2 is new New_Pak1.Pak2;
    package New_Pak3 is new New_Pak2.Pak3;   -- legal??
end Pak4;

It seems as though this ought to be illegal (since New_Pak3 doesn't occur
in a private part or body), but I don't think the wording in the RM
supports this.  The instantiation is still within the scope of the WITH
clause for Pak1.Pak2.Pak3, since using PRIVATE on PRIVATE WITH doesn't
affect the scope of the WITH clause---it just makes certain uses to the
library unit name illegal in certain places.  Therefore 10.1.1(19) still
applies.  But nothing in 10.1.2(12-16) makes this illegal either, because
it only makes illegal certain uses of "A _name_ denoting a library item
that is visible due to being mentioned in one or more with_clauses that
include the reserved word PRIVATE"; and there is no _name_ in the body
of Pak4 that denotes Pak1.Pak2.Pak3 (New_Pak2.Pak3 certainly does not
denote this library item).

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

From: Tucker Taft
Sent: Friday, August 22, 2008  11:04 AM

Yes this is supposed to be illegal, and yes it looks like the wording
is inadequate in general to properly handle children of generics.

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