C# compiler should be able to avoid error CS0118 in many cases

[DaRosenberg]

This is probably my number one nuisance with C# at the moment.

Consider this code:

using OtherNamespace;

namespace Alpha.Beta.Namespace1
{
    class SomeClass
    {
        void SomeMethod(Beta a) { } // Error CS0118: 'Beta' is a namespace but is used like a type
        void OtherMethod(Gamma g) { } // Works fine
    }
}

namespace OtherNamespace
{
    class Beta { }
    class Gamma { }
}

Because Beta happens to form part of the current namespace, it cannot be used as a type.

IMO this error makes no sense, because:

1. Even if both the namespace Beta and the type Beta are technically in scope, specifying only a namespace without any type is not valid in the context (in fact, only places I can think of where it is valid, are nameof() and the namespace declaration itself)
2. Beta is not a root namespace. Nor is it a child namespace of the current namespace Alpha.Beta.Namespace1. How come the namespace Beta is even considered in scope in this context in the first place?

(Point 2 discussed in comments.)

Point 1 is the primary one though. Shouldn't the compiler be able to infer that I'm referring to the type, given that a namespace makes no sense in this location?

[svick]

How come the namespace Beta is even considered in scope in this context in the first place?

Because when you're inside a namespace, you automatically get access to members of that namespace, but also to members of its parent namespaces (including the global namespace).

[DaRosenberg]

Because when you're inside a namespace, you automatically get access to members of that namespace, but also to members of its parent namespaces

Right... That does seem intuitive and familiar, when formalised like that. I guess C# has worked like that since inception. I guess the part I'm not expecting is that this applies also to namespace "nodes" themselves (even ones that don't contain any types) and that by declaring A.B.C I am also declaring A and A.B even though they contain nothing else...

Anyway, that's obviously by very old and very deliberate design, and I don't want to sidetrack the main point with this, so I'll update the issue.

[PathogenDavid]

This doesn't scale when you consider referring to nested symbols. For example:

using OtherNamespace;

namespace Alpha.Beta.Namespace1
{
    class SomeClass
    {
        void AMethod(Beta.TypeInsideBeta a) { } // Beta here is the namespace
        void SomeMethod(Beta a) { } // (With the proposed change) Beta here is the type OtherNamespace.Beta
        void OtherMethod(Gamma g) { } // Works fine
    }
}

namespace Alpha.Beta
{
    class TypeInsideBeta { }
}

namespace OtherNamespace
{
    class Beta { }
    class Gamma { }
}

Beta has a different meaning in both AMethod and SomeMethod. Also consider how this would be extra confusing if there was a nested type OtherNamespace.Beta.TypeInsideBeta too.

You could argue that the compiler should search within the Beta namespace first (to preserve the behavior today) and then only search elsewhere if the lookup fails, but IMO this would be confusing (a human can't easily reason about what Beta refers to in any given context) and would be a departure of how C# normally performs binding.

This is probably my number one nuisance with C# at the moment.

I'd strongly recommend using type aliases for situations like this).

[iam3yal]

@DaRosenberg Preference aside. Why wouldn't you declare it inside Alpha.Beta.Namespace1? like so:

namespace Alpha.Beta.Namespace1
{
    using OtherNamespace;
    
    class SomeClass
    {
        void SomeMethod(Beta a) { } // Works fine
        void OtherMethod(Gamma g) { } // Works fine
    }
}

[DaRosenberg]

@eyalsk thank you, that seems like a viable workaround actually!

For my understanding, why does that work exactly? 😅

As an aside: while that does compile, it also yields a warning:
IDE0065: Using directives must be placed outside of a namespace declaration [Alpha.Beta.Namespace1]
But I'm happy to either suppress or configure that in .editorconfig.

[jmarolf]

I'll just note that VB has this feature. We've jokingly referred to it as 'quantum namespaces'. Essentially because Visual Basic does not have the ability to nest namespaces (and therefore change the order in which they are considered) it must instead attempt to bind all namespaces/types in scope and only issues an error when the type/namespace does not match anything. Considering how complex namespace resolution already is I prefer the canonical solution to this proposal: move the using statements inside the namespace declaration.

[CyrusNajmabadi]

As an aside: while that does compile, it also yields a warning:

That should only warn if you have that setting set.