Confused about namespaces and overload resolution

[thomaslevesque]

I just noticed something really weird.

I maintain a library that provides extension methods to IEnumerable<T>. This library exposes a ToHashSet method. Everything worked fine, until Enumerable.ToHashSet was also introduced in net472, netcoreapp2.0 and netstandard2.1. Predictably, this caused an ambiguous invocation error when both the Linq.Extras and System.Linq namespaces were imported. So far so good, it makes sense.

I set out to fix the issue in my library by adding additional targets without the ToHashSet method, but then I realized something strange: I should have encountered the problem in my tests, but I didn't. My tests target multiple TFMs, including netcoreapp2.0, and look roughly like this:

using System.Linq;

namespace Linq.Extras.Tests
{
    public class MyTests
    {
        [Fact]
        public void Test1()
        {
            IEnumerable<string> enumerable = new[]{ "hello", "world", "HELLO" };
            var result = enumerable.ToHashSet(StringComparer.OrdinalIgnoreCase);
            ...
        }
    }
}

Notice that in this test, both System.Linq.Enumerable.ToHashSet and Linq.Extras.XEnumerable.ToHashSet are in scope. So I should get an ambiguous invocation error... But I don't! It always uses Linq.Extras.XEnumerable.ToHashSet.

The only reason I can think of is that the test namespace (Linq.Extras.Tests) is "under" the namespace the contains the extension method (Linq.Extras). And indeed, if I change the test namespace to Foo and add a using Linq.Extras, I get the expected error.

So, is this behavior expected? Is there an overload resolution rule that prioritizes extension methods in a parent namespace? Where is this rule mentioned?

[thomaslevesque]

OK, answering my own question. I found the relevant section in the C# 5 spec (since no spec is available for later versions), §7.6.5.2:

• Starting with the closest enclosing namespace declaration, continuing with each enclosing namespace declaration, and ending with the containing compilation unit, successive attempts are made to find a candidate set of extension methods:
  • If the given namespace or compilation unit directly contains non-generic type declarations Ci with eligible extension methods Mj, then the set of those extension methods is the candidate set.
  • If namespaces imported by using namespace directives in the given namespace or compilation unit directly contain non-generic type declarations Ci with eligible extension methods Mj, then the set of those extension methods is the candidate set.

This behavior was surprising to me, but it's working as specified.

[thomaslevesque]

(And it should have been a discussion rather than an issue... Sorry about that, I'm not yet used to the new discussions feature.)