CVS difference for ais/ai-00150.txt

--- ais/ai-00150.txt	1998/09/30 23:25:15	1.2
+++ ais/ai-00150.txt	1999/08/16 19:52:42	1.3
@@ -1,5 +1,6 @@
-!standard 08.03    (26)                               98-06-12  AI95-00150/04
+!standard 08.03    (26)                               99-08-13  AI95-00150/05
 !class binding interpretation 96-09-04
+!status Corrigendum 2000 99-08-13
 !status WG9 approved 98-06-12
 !status ARG Approved 10-0-1  98-04-01
 !status ARG Approved (with changes) 13-0-0  97-11-16
@@ -10,13 +11,13 @@
 !difficulty Medium
 !subject Uniqueness of Component Names
 
-!summary 98-03-27
+!summary
 
 For a type extension declared in a child package, where the parent type
 is declared in an ancestor package, it is illegal for the two types to
 have duplicate component names.
 
-!question 96-09-08
+!question
 
 Consider the following example, inspired by ACVC test C730003:
 
@@ -38,14 +39,16 @@
 Both DT and DDT contain components called Y.  Is this name duplication
 legal?  (No.)
 
-!recommendation 96-09-08
+!recommendation
 
 (See summary.)
 
-!wording 96-09-08
+!wording
 
-!discussion 98-03-27
+(See corrigendum.)
 
+!discussion
+
 3.4(14) says:
 
    Declarations of components, protected subprograms, and entries,
@@ -79,8 +82,47 @@
 Note that if DDT were declared in another root library unit, rather than
 in a child of Parent, then the two Y's would be legal, since there would
 be no place where both are visible.
+
+!corrigendum 8.03(26)
+
+@drepl
+An explicit declaration is illegal if there is a homograph occurring
+immediately within the same declarative region that is visible at the place
+of the declaration, and is not hidden from all visibility by the explicit
+declaration. Similarly, the @fa<context_clause> for a subunit is illegal if it
+mentions (in a @fa<with_clause>) some library unit, and there is a homograph of
+the library unit that is visible at the place of the corresponding stub, and
+the homograph and the mentioned library unit are both declared immediately
+within the same declarative region. These rules also apply to dispatching
+operations declared in the visible part of an instance of a generic unit.
+However, they do not apply to other overloadable declarations in an instance;
+such declarations may have type conformant profiles in the instance, so long
+as the corresponding declarations in the generic were not type conformant.
+@dby
+An explicit declaration is illegal if there is a homograph occurring
+immediately within the same declarative region that is visible at the place
+of the declaration, and is not hidden from all visibility by the explicit
+declaration. In addition, in a type extension of a type declared in an ancestor
+package, a component declaration is illegal if two components, both visible in
+the private part of the child, are homographs. Similarly, the
+@fa<context_clause> for a subunit is illegal if it mentions (in a
+@fa<with_clause>) some library unit, and there is a homograph of the library
+unit that is visible at the place of the corresponding stub, and the homograph
+and the mentioned library unit are both declared immediately within the same
+declarative region. These rules also apply to dispatching operations declared in
+the visible part of an instance of a generic unit. However, they do not apply to
+other overloadable declarations in an instance; such declarations may have type
+conformant profiles in the instance, so long as the corresponding declarations
+in the generic were not type conformant.
+
+!ACATS test
+
+Create a B-Test out of the example above. Resurrect C730003 to check that
+names CAN be duplicated in library packages (not children), as noted by this
+ruling. This should insure implementations allow duplicate names only as allowed
+by the standard.
 
-!appendix 96-09-04
+!appendix
 
 !section 8.3(26)
 !subject 3.9.1(9) & 8.3 don't preclude non-unique component names
@@ -190,5 +232,36 @@
 -Tuck
 
 ----- End Included Message -----
+
+****************************************************************
+
+!from Robert Eachus 99-08-08
+!discussion
+
+Note that the rule as stated in the corrigendum is slightly different from the
+recommendation.  This is to correctly deal with the case where the parent
+declaration is derived from another private type, which is not declared in an
+ancestor of the child package:
+
+package A is
+    type Foo is tagged private;
+private
+    type Foo is  tagged record  I: Integer; end record;
+end A;
+
+with A;
+package B is
+    type New_Foo is new A.Foo with private;
+private
+    type New_Foo is new A.Foo with record J: Integer; end record;
+end B;
+
+package B.C is
+     type Newer_Foo is new B.New_Foo with record
+        I: Integer; --legal
+        J: Integer; --illegal
+     end record;
+end B.C;
+}
 
 ****************************************************************