Roslyn: Why are interface members allowed to make use of static return / parameter types?

[stakx]

I originally posted an issue over at https://github.com/dotnet/csharplang/issues/2739, reposting here because @CyrusNajmabadi suggested this might be a compiler bug.

---

Version Used:

• Visual Studio Community 2019
  VisualStudio.16.Release/16.2.2+29209.62
  C# Tools 3.2.0-beta4-19380-04+5e176ad8aea2724fe6787495c6fcc9144c550de1

Steps to Reproduce:

Compile the following program fragment and observe any compilation errors:

static class StaticClass { }

interface IX
{
    StaticClass P { get; }
    StaticClass M(StaticClass p);
}

class X : IX
{
    public StaticClass P => throw new NotImplementedException();
    public StaticClass M(StaticClass p) => throw new NotImplementedException();
}

Expected Behavior:

I would expect the C# compiler to complain about the uses of StaticClass as a return type and parameter type, both in types IX and X.

Actual Behavior:

The C# compiler only produces errors for the (invalid?) uses of StaticClass in X. There are no errors in IX, i.e. if I omit the definition of class X, the above program fragment will compile successfully. Which is obviously nonsensical, since there's no way to sensibly implement IX.P nor call IX.M.

[RikkiGibson]

This also repros in VS 16.2.3 (C# tools 3.2.1-beta4-19408-03+2fc6a04980f800c59e8ede97e6ae294ff47d666e).

[RikkiGibson]

This is present in dev15.

[RikkiGibson]

Also, this doesn't seem to be affected by whether the interface method has a default implementation.

[stakx]

I did run the repro in VS 2013 as well, so this behavior has been around for a few years at least.

[333fred]

VS 2013

This means this behavior was in the native compiler as well. We'll have to look into whether or not we intentionally replicated behavior from the native compiler.

[stakx]

whether or not we intentionally replicated behavior from the native compiler

If that turns out to be the case, I'd be interested to learn about the assumed benefits of staying compatible in this case. If there's a scenario where such code makes (or made) any sense at all, I'd like to hear about it.

[333fred]

https://github.com/dotnet/roslyn/blob/master/src/Compilers/CSharp/Test/Symbol/Symbols/SymbolErrorTests.cs#L13187-L13228

This is an intentional backcompat shim with Dev10. Since you can't actually implement an interface defined like this, we're going to Won't Fix this since you can't actually get into any bad behavior.

[CyrusNajmabadi]

@333fred @gafter. This should likely be marked for warning waves

[RikkiGibson]

Should we continue to allow this when the interface member has a default implementation?