Re: Anonymous Namespaces

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Alexandre Oliva <aoliva@redhat.com> writes:

| On Feb 12, 2004, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
| 
| > Alexandre Oliva <aoliva@redhat.com> writes:
| > | On Feb 11, 2004, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
| > | 
| > | > Alexandre Oliva <aoliva@redhat.com> writes:
| > | 
| > | > | Here's my reasoning.  Please point out any flaws in it:
| > | > | 
| > | > | - If it's not a template, then the reference to the symbol is either
| > | > |   template-independent (so it's bound at parse time, and we can
| > | > |   determine immediately that the name can't be marked as local to the
| > | > |   translation unit), or it's referenced for being a template argument
| > | > |   passed to the exported template (in which case we know it can't be
| > | > |   used as an argument to the exported template in another translation
| > | > |   unit, because you can't reference the name in another unit, so you
| > | > |   can't get to that particular exported template instantiation, so the
| > | > |   name can remain local to the translation unit as well)
| > | 
| > | > I don't follow.  Argument dependent name lookup may hit a
| > | > non-template,
| > | 
| > | How?  I can only see it do so by means of typedefs, and this is the
| > | case we'd catch by the transitive closure case I mentioned.  Am I
| > | still missing anything?
| 
| > Did you look at the example I gave?
| 
| Yes.  Ok, so my use of `typedefs' wasn't entirely appropriate, since I
| was considering template typename arguments as equivalent to
| typedefs.

Yes.  That view won't work because argument dependent name lookup does
not consider "associated namespaces/classes of typedefs".  And even if
it did, it will just contribute more scopes to explore (not remove any).

|  If you consider them as such, you can still decide
| precisely which versions of gunc() to export or not, even if n::func()
| was exported, because the type arguments passed to n::func have to be
| visible in order for an external entity to reference them.

I don't understand what you call "visible" in this case.  The precise
rules that govern argument dependent name lookup don't talk about
"visible" types.   

At instantiation time, you typecheck constructs in the template body
(which usually will be in a different translation than the one that
requested the instantiation). Such template can (and will) contain
function call that weren't resolved at the template definition time.
For calls that need argument dependent name lookup (the arguments here
are the arguments used to call the function, not those used to
instantiate the template), you look at the types of the arguments, you
build associated classes and namespaces and you go find the collection
of candidate names.  This second phase of name lookup is initiated by
a translation unit that is independent of the translation unit that
requested the instantiation.  And if that translation unit made
uninformed decisions (because it thaught that the name in an unnamed
namespace was not used in that translation unit), then it will foul
the second phase of the name lookup.

The fundamental problem, I believe, is the lack of language construct
to express the requirements of a template on its arguments.  I.e., if
you had a way to enable checking of template separately, both at
     (1) definition point
     (2) use point

(just like for ordinary functions) then you could make those decisions
without having to know what may happen latter.  As currently defined,
(exported) template instantiations still depend on the context of
instantiation which makes "early" decisions very premature/wrong.
 
-- Gaby