Visibility of subprogam names within instantia 87-01-13 AI-00370/06 1 | !standard 08.03 (16) 87-01-13 AI-00370/06 !class ramification 86-01-24 !status approved by WG9/AJPO 86-07-22 !status approved by Director, AJPO 86-07-22 !status approved by WG9/Ada Board 86-07-22 !status approved by Ada Board 86-07-22 !status approved by WG9 86-05-09 !status committee-approved (8-0-0) 86-02-20 !status work-item 86-01-24 !status received 85-07-30 !references 83-00588 !topic Visibility of subprogam names within instantiations !summary 86-02-27 Any declaration with the same designator as a subprogram instantiation is not visible, even by selection, within the instantiation. !question 86-01-28 Consider the following example: package PACKAGE_1 is generic procedure PROCEDURE_1; end PACKAGE_1; with PACKAGE_1; package PACKAGE_2 is procedure PROCEDURE_1 is new PACKAGE_1.PROCEDURE_1; -- * -- end PACKAGE_2; According to 8.3(16), the starred line is illegal, since we are within a generic instantiation that declares a subprogram and therefore "every declaration with the same designator as the subprogram is hidden" and "where hidden in this manner, a declaration is visible neither by selection nor directly." In view of the example, was 8.3(16) as written the intent? Or was the intent closer to the following? Where hidden in this manner, a declaration is also not visible by selection if its expanded names are the same as those containing the subprogram specification or generic instantiation. (Expanded names, not name, because packages can be renamed.) !response 86-03-04 8.3(16) says: Within the specification of a subprogram, every declaration with Visibility of subprogam names within instantia 87-01-13 AI-00370/06 2 the same designator as the subprogram is hidden; the same holds within a generic instantiation that declares a subprogram, and within an entry declaration or the formal part of an accept statement; where hidden in this manner, a declaration is visible neither by selection nor directly. Consider the following example: package PACK is function F return INTEGER; function F (I : INTEGER := PACK.F) return INTEGER; -- illegal end PACK; By 8.3(16), the use of F in the default expression is illegal. Without this restriction, one is faced with the problem of how to determine whether a call like PACK.F denotes the containing function specification F before processing of that specification is completed, that is, before there is even a parameter and result type profile for F that can be used in overload resolution. The restriction of 8.3(16) is needed also for generic subprogram instantiations because if the generic subprogram has a formal subprogram parameter and/or a formal 'in' parameter, then the corresponding actual parameters in an instantiation can cause a similar kind of overload resolution problem as illustrated above for a non-generic subprogram. For example: generic J : INTEGER; function GF (I : INTEGER := J) return INTEGER; package PACK is function F return INTEGER; function F is new GF (PACK.F); -- illegal end PACK; | !appendix 87-01-13 | | ***************************************************************************** | | !section 08.03 (16) Geoff Mendal 86-12-04 83-00870 | !version 1983 | !topic Assumption in AI-00370/05 | | The very last example in AI-00370/05 assumes that both | declarations are inside the same declarative region, and | are not each compilation units. This must be so since | if each were compilation units, the use of "is new GF (PACK.F)" | would be semantically invalid since no visibility to GF | has been established. I would suggest placing these | declarations in a declare block, or adding a context | clause ("with GF") to package PACK.