Version 1.1 of ais/ai-00150.txt
!standard 08.03 (26) 98-04-01 AI95-00150/03
!class binding interpretation 96-09-04
!status ARG Approved 10-0-1 98-04-01
!status ARG Approved (with changes) 13-0-0 95-11-01
!status work item 96-09-06
!status received 96-09-04
!subject Uniqueness of Component Names
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.
Consider the following example, inspired by ACVC test C730003:
package Parent is
type T is tagged ...;
type DT is new T with private;
type DT is new T with record
package Parent.Child is
type DDT is new DT with record
Y: ...; --
Both DT and DDT contain components called Y. Is this name duplication
Declarations of components, protected subprograms, and entries,
whether implicit or explicit, occur immediately within the
declarative region of the type, in the order indicated above,
following the parent subtype_indication.
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.
It appears that this rule does not apply to the second declaration of Y,
above, because the inherited Y is not visible at this place. However,
the inherited Y later does become visible, since DDT is in a child
package. This is intended to be illegal -- components are not intended
to be overridable; nor are they allowed to be overloadable.
The problem is that 8.3(26) and other parts of 8.3 are based on whether
certain declarations are implicit or explicit. This leads to the
problem addressed by this AI. See also AI95-44, which addresses other
problems with the same underlying cause.
The intent is that two or more homographs are not allowed immediately
within the same declarative region, if there is a place where both are
visible, unless all but one are overridden. (Note however, that this
rule does not apply in instances!)
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.
!subject 3.9.1(9) & 8.3 don't preclude non-unique component names
!reference RM95-8.3(26), RM95-3.9.1(9)
!from Dan Lehman
!reference 96-5601.a Dan Lehman 96-6-14>>
ACVC 2.0 (& 2.0.1) test C730003 shows an unintended consequence of
changes to the wording of 8.3(26) which contradicts note 3.9.1(9)'s
assertion that "each visible component of a record extension has to have
a unique name." C730003 declares a private extension in a parent package
from which a child package declares a type extension in the visible part;
at this point, there is no rule forbidding the naming of a new component
with the same name of a component of the parent type declared in the private
part of the parent package--for that characteristic of the parent type
is not visible until the (implicit) private part of the child package.
But 8.3(26) only makes a homograph declaration illegal if "there is a
homograph occurring immediately within the same declarative region THAT
IS VISIBLE AT THE PLACE OF THE DECLARATION," which is not the case in
C730003. An attempt to refer to either homograph is illegal by 8.3(24);
but 8.3(26) should probably be strengthened to make the declaration illegal.
Below is discussion of this issue regarding a petition against the
----- Begin Included Message -----
From: firstname.lastname@example.org Thu Jun 13 17:56:23 1996
> The following is from an e-mail message from Tucker Taft:
> > I agree this is illegal. However, I did have some trouble finding the
> > exact wording. The intent is clear from RM95-3.9.1(9), but you need
> > to combine RM95-3.4(12,14), 7.1(6), 7.3(15), 7.3.1(4), and 8.3(26)
> > to cover this particular case. The derived type Graphic_Card has an
> > inherited component named "View" implicitly declared at the point where
> > C730003_0.C730003_1 gains visibility on the private part of its parent
> > unit, which occurs at the beginning of its own (implicit) private part.
> > At this point, it violates 8.3(26), making the compilation illegal.
> Here is a compiler listing for the test:
> 167 View : Graphic_Representation; -- (B)
> ^^^^ -- "Duplicate" component field name
> >>>> Error: Illegal to override declaration in same region, LRM:8.3(26)
> I concur in the sentiment that 3.9.1(9) shows that the code above is
> wrong, but I disagree with the petitioner/implementation & Tuck about
> exactly why it's wrong. Tuck's msg. admits that he had trouble finding
> "the exact wording" to support the petition; I submit that he in fact
> didn't find it, but came close enough for others to find it. In short,
> 8.3(26) doesn't cover the case at hand because it applies only where the
> implicit declaration "is visible AT THE PLACE OF the (explicit) declaration,
> which is not the case in C730003 and which is the point of the test; but
> 8.3(24) seems to apply to later code where the selector_name "View" must
> be resolved but is ambiguous (for the derived type).
> Tuck's citations lead one to conclude that, at some point after the last
> declaration in the visible part of the child package, the inherited implicit
> declaration of component View from the parent becomes visible. But this is
> too late for 8.3(26)'s restriction to apply and make the declaration of a
> homograph @167 illegal. So, there must at this point, immediately before
> the end of the package declaration, be two Views (that one can't use)--I
> don't see any rule to forbid this.
I guess I agree. I was concluding that the declaration of the inherited
component was illegal by 8.3(26), but I now see that 8.3(26) only applies
to explicit declarations. It turns out we had more correct, but arguably
more obscure, wording in an earlier version of Ada 9X (version 4.0),
in paragraph 8.3(24):
A compilation unit is illegal if it contains a place where two explicit
homographs that occur immediately with the same declarative region are
simultaneously visible. ...
Unfortunately, this suffers from the requirement that both be "explicit."
As we have noted elsewhere, the whole distinction between explicit and
implicit declarations is bogus, and creates all kinds of bizarre notions
like explicit implicit declarations inside generic instances, etc..
The key distinction is between "inherited primitives", and all others.
Inherited primitives may be overridden. Nothing else may be overridden,
independent of whether it is explicit or implicit.
The correct rule is:
It is illegal to have two simultaneously visible homographs declared
immediately in the same declarative regions, unless one or both
are inherited primitives.
> Should there be an AI to make the above case indeed an illegality of 8.3(26),
> to manifest the hope of note #69 (3.9.1:9) there?
Yes, we should have an AI that rewrites all of this garbage about
implicit vs. explicit in terms of inherited primitives vs. others.
----- End Included Message -----
Questions? Ask the ACAA Technical Agent