!standard E.2.1    (07)                               99-09-15  AI95-00003/02
!class binding interpretation 95-06-25
!status Corrigendum 2000 99-05-24
!status WG9 approved 96-12-07
!status ARG approved 7-0-1  96-06-17
!status work item 95-06-25
!status received 95-06-25
!priority Medium
!difficulty Medium
!qualifier Error
!subject Access types declared in shared passive generic packages

!summary

A declaration of an access type that designates a class-wide type, task
type, or protected type with entry_declarations is allowed within a
block_statement in the sequence_of_statements of a generic shared
passive package.

!question

E.2.1(7) states that a shared passive library unit "shall not contain a
library-level declaration of an access type that designates a class-wide
type, task type, or protected type with entry_declarations; if the
shared passive library unit is generic, it shall not contain a
declaration for such an access type unless the declaration is nested
within a body other than a package_body."

This allows such an access type in a block_statement in the
sequence_of_statements of the body of a package, but not of a generic
package (since a block_statement is not a "body other than a
package_body").  Is this intended?  (No.)

!recommendation

(See summary.)

!wording

Delete "; if the shared passive library unit is generic, it shall not
contain a declaration for such an access type unless the declaration is
nested within a body other than a package_body".

!discussion

The intent of the part of E.2.1(7) after the semicolon is to forbid
certain access types in a generic shared passive package, unless the
access type is declared within a master.  3.10.2(20) says:

   For determining whether one level is statically deeper than
   another when within a generic package body, the generic package
   is presumed to be instantiated at the same level as where it was
   declared; run-time checks are needed in the case of more deeply
   nested instantiations.

This implies that the part of E.2.1(7) after the semicolon is redundant,
except in the case of block_statements.  The block_statement case was
not intended to be forbidden (and is not forbidden in the non-generic
case).  Thus, these words should be deleted.

!corrigendum E.02.01(7)

@drepl
@xbullet<it shall not contain a library-level declaration of an access
type that designates a class-wide type, task type, or protected
type with @fa<entry_declaration>s; if the shared passive library unit
is generic, it shall not contain a declaration for such an access
type unless the declaration is nested within a body other than a
@fa<package_body>.>
@dby
@xbullet<it shall not contain a library-level declaration of an access
type that designates a class-wide type, task type, or protected
type with @fa<entry_declaration>s.>

!ACATS test

A test is needed. There ought to be a C-Test that access types are
allowed in blocks in generic bodies.

!appendix

!section E.2.1(07)
!subject Wording appears unnecessarily complicated; is there a hidden subtlety?
!reference RM9X-E.2.1(7);5.95
!from Norman Cohen
!reference as: 94-5035.b Norman H. Cohen 94-12-19>>
!discussion

A shared passive library unit "shall not contain a library-level
declaration of an access type that designates a class-wide type, task
type, or protected type with entry_declarations; if the shared passive
library unit is generic, it shall not contain a declaration for such an
access type unless the declaration is nested within a body other than a
package_body."

Given the definition of accessibility levels within a generic-package
body in 3.10.2(20), is the part after the semicolon meant to say anything
different from what is already said by the part before the semicolon?

(I do see one difference, but I suspect it is not intended:  The
forbidden access-type declarations are allowed within a block statement
in the sequence of statements of a package body, which is not library
level because block statements are masters (3.10.2(3)); however, such
declarations are not "nested within a body other than a generic body," so
the access type declarations are not allowed within the sequence of
statements of a GENERIC package body!)

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

!section E.2.1(07)
!subject Wording appears unnecessarily complicated; is there a hidden subtlety?
!reference RM9X-E.2.1(7);5.95
!reference 94-5035.b Norman H. Cohen 94-12-19
!from Bob Duff
!reference as: 94-5037.b Bob Duff 94-12-19>>
!discussion

> A shared passive library unit "shall not contain a library-level
> declaration of an access type that designates a class-wide type, task
> type, or protected type with entry_declarations; if the shared passive
> library unit is generic, it shall not contain a declaration for such an
> access type unless the declaration is nested within a body other than a
> package_body."
>
> Given the definition of accessibility levels within a generic-package
> body in 3.10.2(20), is the part after the semicolon meant to say anything
> different from what is already said by the part before the semicolon?
>
> (I do see one difference, but I suspect it is not intended:  The
> forbidden access-type declarations are allowed within a block statement
> in the sequence of statements of a package body, which is not library
> level because block statements are masters (3.10.2(3)); however, such
> declarations are not "nested within a body other than a generic body," so
> the access type declarations are not allowed within the sequence of
> statements of a GENERIC package body!)

I believe you are correct.  This is an unexpected side-effect of
shifting the wording about levels of generics.

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