6

I have a generic class X<T>; This class has a covariant part that I want to be able to access covariantly. So I factor it out into an interface IX<out T>. However, I want this interface to be visible only to the class itself, because it contains also methods that are ment to be private.

I.e., inside the class itself, I can upcast to IX<T> and use it covariantly. E.g.:

class X<T> : IX<T> {

    private interface IX<out T>{ // the private covariant interface
         void foo();
    }

    // It grants access to the private method `foo`
    private T foo(){...}
    public T IX.foo(){ return foo(); }

    private static void someMethod(IX<T> x) {
        // Here I can use `x` covariantly
    }
}

Is this possible? I have never heard of private nested interfaces before, since a private interface usually makes no sence at all. However, with generics such an interface becomes necessary for implementing "private-only covariance".

When I try to compile this, I receive the following error:

foo.cs(1,14): error CS0246: The type or namespace name `IX' could not be found. Are you missing an assembly reference?
foo.cs(9,14): error CS0305: Using the generic type `X<T>.IX<S>' requires `1' type argument(s)

Which is basically clear, an inner type of a generic type needs a type parameter for the outer type. Is there a way to get this code to compile correctly?

gexicide
  • 38,535
  • 21
  • 92
  • 152

2 Answers2

9

Edit: it looks like this compiles on the Roslyn / C# 6 tech preview, but does not compile on the MS C# 5 compiler or the mono compiler.

Yes, like this - but note that actually the inner T is unnecessary in many ways, and if you retain it - it would be useful to name it TInner or something to avoid confusion, since the T in X<T> is technically a different thing than X<>.IX<T>, even though they will always be the same actual type in practice:

class X<T> : X<T>.IX<T>
{

    private interface IX<out TInner>
    { // the private covariant interface
        void foo();
    }

    // It grants access to the private method `foo`
    private T foo() { throw new NotImplementedException(); }
    void X<T>.IX<T>.foo() { throw new NotImplementedException(); }

    private static void someMethod(IX<T> x)
    {
        // Here I can use `x` covariantly
    }
}
Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900
  • Seems odd that something that's `private` to a class can be accessed externally (i.e. outside the class). – James Jul 18 '14 at 09:06
  • @James it *isn't* accessed externally. – Marc Gravell Jul 18 '14 at 09:06
  • So it can't be accessed from another class in the same assembly via `X.IX`? – James Jul 18 '14 at 09:07
  • 1
    @James no; it can only be used by `X` and other types declared *inside* `X`. – Marc Gravell Jul 18 '14 at 09:08
  • Ah, neat didn't know that +1 :) – James Jul 18 '14 at 09:08
  • @James you would not be able to declare a `X.IX` reference anywhere else. – Dave Cousineau Jul 18 '14 at 09:08
  • 1
    This causes a compiler error: Circular base class dependency involving 'X' and 'X.IX' – Mike Zboray Jul 18 '14 at 09:09
  • @mikez compiles just fine here; what compiler are you using? I'm using the Roslyn preview – Marc Gravell Jul 18 '14 at 09:10
  • Just fired it up in an IDE and I get the same circular ref error, that's in VS2012 – James Jul 18 '14 at 09:11
  • I believe I copied correctly. See [this](https://dotnetfiddle.net/eMaQCj). It might be fixed in a newer build of Roslyn. I don't doubt that. – Mike Zboray Jul 18 '14 at 09:12
  • @MarcGravell: I tried it with the mono compiler: Same error. Was there a change in the specification to allow this or are simply all compilers except the Roslyn preview buggy? – gexicide Jul 18 '14 at 09:23
  • @gexicide I genuinely don't know; it is intriguing – Marc Gravell Jul 18 '14 at 09:24
  • @gexicide some folks in the know have clarified that this would be considered a fix in Roslyn – Marc Gravell Jul 18 '14 at 17:21
  • Yes. This is a fix in Roslyn. In some cases the the old compiler was too strict in its cycle analysis. Roslyn tries to enforce just the minimally required set of rules. – VSadov Jul 18 '14 at 21:58
  • It's interesting "linguistically" but I don't understand how it can be useful in real life design. When we said using a method covariantly for a parameter T, we know which type T' is it's subclass. Example like void f(SomeClass x), we can pass a type x' which is SomeClass because we are certain Dog is a subclass of Animal. Inside a generic class X, we don't know what T will be used as parameter when X is instantiated, because T could be anything. So the private method void someMethod(IX x) in this question how can you find a T' which is definitely a subclass of T? – palazzo train Sep 23 '14 at 03:16
-1

In order for it to compile and limit the visibility of your interface just to your assembly you can mark it as internal. The thing is if it's declared as an inner type it won't be seen by your class. This code should work:

internal interface IX<out T> // the private covariant interface
{ 
    T foo();
}

class X<T> : IX<T> 
{
    // It grants access to the private method `foo`
    private T foo(){ return default(T); }
    T IX<T>.foo(){ return foo(); }

    private static void someMethod(IX<T> x)
    {
        // Here I can use `x` covariantly
    }
}

This way the interface is still private, but as it's not an inner type anymore it can be used on your class.

LazyOfT
  • 1,428
  • 7
  • 20
  • 1
    Are `private` interfaces at namespace level allowed? I thought only `internal` and `public` was allowed there... Yep, tried it. Got a compiler error stating exactly this. – gexicide Jul 18 '14 at 09:23
  • You're right, I tested it using Linqpad, which apparently puts everything inside an inner class. – LazyOfT Jul 21 '14 at 11:55