[Bug c++/26448] New: unnecessary namespace-alias ambiguity

[Bug c++/26448] New: unnecessary namespace-alias ambiguity

[emilp at mac dot com]

namespace lib1
{
    namespace part
    {
        typedef int result;
    }
}

namespace lib2
{
    namespace part = lib1::part;
}

using namespace lib1;
using namespace lib2;

int main()
{
    part::result val = 0;
    return val;
}

The above code results in a compilation error,  "error: `part' has not been
declared", but should it really? I can't say the parts of the C++ standard I've
read has been clear on the point, but it seems reasonable that the compiler
should recognize that "part" is not ambiguous in this case.


-- 
           Summary: unnecessary namespace-alias ambiguity
           Product: gcc
           Version: 4.0.1
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: emilp at mac dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26448

[Bug c++/26448] unnecessary namespace-alias ambiguity

[bangerth at dealii dot org]

------- Comment #1 from bangerth at dealii dot org  2006-03-08 04:52 -------
My understanding is that this code is in fact invalid (and icc
agrees with me). You may consider this part of the standard
gratuitously unfriendly, but remember that namespace aliases form
a directed graph and proving that two paths in the graph lead to the
same node is not necessarily a cheap task.

W.


-- 

bangerth at dealii dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bangerth at dealii dot org
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26448

[Bug c++/26448] unnecessary namespace-alias ambiguity

[emilp at mac dot com]

------- Comment #2 from emilp at mac dot com  2006-03-08 08:45 -------
But isn't this problem already solved for the "using" directive. The code below
compiles fine and works as expected. In fact, in the days of gcc 3, "using"
could be used for namespaces and behaved exactly the way I would prefer.

namespace lib1
{
    typedef int integer;
}

namespace lib2
{
    using lib1::integer;
}

using namespace lib1;
using namespace lib2;

int main()
{
    integer val = 0;
    return val;
}

It seems limiting to introduce new (and often obscure) ambiguities when using
namespace aliases, the very problem namespaces are meant to alleviate...

E.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26448

[Bug c++/26448] unnecessary namespace-alias ambiguity

[bangerth at dealii dot org]

------- Comment #3 from bangerth at dealii dot org  2006-03-08 14:59 -------
I didn't make up the rules, so you're barking up the wrong tree :-)

But the difference between using directives for names and namespace
aliases is that a using directive is final: it imports a name into
the present namespace. The namespace alias provides an alternative
name for a namespace, but the namespace name it points to may itself
be an alias, which means that the compiler may have to walk a fairly
long chain of aliases until it finally finds the original.

W.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26448

[Bug c++/26448] unnecessary namespace-alias ambiguity

[emilp at mac dot com]

------- Comment #4 from emilp at mac dot com  2006-03-08 15:23 -------
I did come on a bit strong, didn't I?  Sorry about that, I'm just a bit
frustrated since it used to work better in the gcc 3 series :-)

Do you have a suggestion as to where I could continue this discussion?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26448

[Bug c++/26448] unnecessary namespace-alias ambiguity

[bangerth at dealii dot org]

------- Comment #5 from bangerth at dealii dot org  2006-03-08 15:26 -------
(In reply to comment #4)
> I did come on a bit strong, didn't I?  Sorry about that, I'm just a bit
> frustrated since it used to work better in the gcc 3 series :-)

Oh, don't worry. I put a smiley to my remark, just in case you didn't
notice :-)


> Do you have a suggestion as to where I could continue this discussion?

There's pretty much only a single route for you, and that is through the
relevant C++ standards committees. A pretty daunting task, if you ask me.

W.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26448

[Bug c++/26448] unnecessary namespace-alias ambiguity

[emilp at mac dot com]

------- Comment #6 from emilp at mac dot com  2006-03-08 16:47 -------
I'm considering filing a defect report (for a standard clarification) to the
commitee but I would like to make sure I'm not climbing any trees here... In
your first reply you said "My understanding is that this code is in fact
invalid...", which part of the C++ standard did you base this on?

I'm just wondering because section 7.3.2 seems not to mention any lookup rules
at all? Am I missing something obvious?

E.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26448

[Bug c++/26448] unnecessary namespace-alias ambiguity

[bangerth at dealii dot org]

------- Comment #7 from bangerth at dealii dot org  2006-03-08 17:21 -------
(In reply to comment #6)
> I'm considering filing a defect report (for a standard clarification) to the
> commitee but I would like to make sure I'm not climbing any trees here... In
> your first reply you said "My understanding is that this code is in fact
> invalid...", which part of the C++ standard did you base this on?

I don't have the time to look that up right now, but you should look this
up in the "name lookup" section. It should say that there is an ambiguity
if a matching name is found in two namespaces. Note that a
   namespace a=b;
declaration introduces a new namespace.

W.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26448