Namespaces And Unqualified Name Lookup

gcc 3.3.3 and MSVC 7.1 disagree on whether a snippet of code is valid,
and I can't tell from the Standard which one is correct.  I believe
that gcc 3.3.3 correctly accepts the code and MSVC 7.1 incorrectly
rejects it.

The code:

namespace meow {
     struct mlar { };
}

namespace oink {
    using namespace meow;

    void fxn(mlar s);
}

void oink::fxn(mlar s) { }

Basically, when a function (fxn) lives in one namespace (oink) that
uses another namespace (meow), can the function's arguments (s) use
unqualified types (mlar), instead of qualified types (meow::mlar)?

I looked at 14882:2003 3.4.1 (6), but I couldn't understand how to
apply it to this example.

Explicit qualification satisfies both gcc 3.3.3 and MSVC 7.1.

Both compilers accept the code when the mlar type lives in the oink
namespace itself, and not a namespace that the oink namespace uses:

namespace oink {
    struct mlar { };

    void fxn(mlar s);
}

void oink::fxn(mlar s) { }

It seems that explicit qualification is needed on return types; that
makes sense to me, since the function's name hasn't been seen yet.
The question is whether explicit qualification is needed on the
arguments (this also applies to types in exception specifications).

Stephan T. Lavavej
 http://www.**--****.com/ 

      [ See  http://www.**--****.com/ ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

 XXXX@XXXXX.COM  (Stephan T. Lavavej) writes:


The example in 3.4.1/6 alone is not sufficient to cover this
    case. You need to combine it with 7.3.4/1 :

    # [...] During unqualified name lookup (3.4.1), the names appear
    # as if they were declared in the nearest enclosing namespace
    # which contains both the using-directive and the nominated
    # namespace. [...]

So I believe gcc 3.3.3 is correct to accept the code, and MSVC 7.1
    wrong to reject it.

[snip]

Are you sure? I don't see that in the standard, and both como online
    and gcc 3.[34] accept:

namespace meow {
     struct mlar { };
}

namespace oink {
    using namespace meow;

    mlar fxn(mlar s); //no qualifcation on return type.
}

meow::mlar oink::fxn(mlar s) { }


      [ See  http://www.**--****.com/ ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[llewelly]

There's no argument about the prototype inside the "namespace oink"
block - the using directive is sitting right on top of it, so you can
omit all qualifications. The question is what happens with the
definition below (and note, you do qualify the return type there).

Since you say Comeau and 3.4 accept the omitted qualification on the
argument in the definition, I'm more inclined to believe that MSVC is
incorrectly rejecting the code, but I'd still like to know what part
of the Standard says this.

      [ See  http://www.**--****.com/ ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

 XXXX@XXXXX.COM  (Stephan T. Lavavej) writes:


I didn't think about the definition. That's why it's return type was
    still qualified in my example.

Comeau and g++ 3.4 accept the omitted qualification on the return
    type *only* if the definition is moved into the namespace oink,
    like this:

    namespace meow {
         struct mlar { };
    }

    namespace oink {
        using namespace meow;
        mlar fxn(mlar s);
        mlar fxn(mlar s) { }
    }

This:    

    namespace meow {
         struct mlar { };
    }

    namespace oink {
        using namespace meow;
        mlar fxn(mlar s);
    }
    mlar oink::fxn(mlar s) { }

is rejected by como and gcc 3.4.

I can't figure out why omitted the qualification on the return type
    when the definition is outside the namespace oink is being
    rejected. I keep looking at 7.3.4/1 and wondering what I am
    missing:

    # [...] During unqualified name lookup (3.4.1), the names appear
    # as if they were declared in the nearest enclosing namespace
    # which contains both the using-directive and the nominated
    # namespace. [...]


Again, I think 7.3.4/1 requires your original example be accepted. On
    the other hand, I also think 7.3.4/1 requires my 2nd example with
    the unqualified return type outside the namespace to be accepted
    as well, since it is inside the nearest enclosing namespace which
    contains both the using-directive and the nominated
    namespace. But como and gcc 3.4 still reject it. Am I wrong? 

      [ See  http://www.**--****.com/ ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]