Allow to make a generic type's limitation to "interface"

[ghost]

We can force a generic type inherted from a class:

 public class XXX<T> where T:class

However we cannot force a generic type implemented by an interface, just like this:

public class YYY<T>where T:interface

Why need this? Some special design mode needs it.—— A typical example is SignalR's latest Hub, here "T" in fact must be an interface for us instead of a fully-filled class or a class implemented from an interface.
Notice it that SignalR is ONLY AN EXAMPLE, and this isn't the core issue from SignalR.

[tmat]

What operations do you perform on T that require the distinction between a class and an interface?

[ghost]

@tmat ：Just like what I said above——In SignalR, Any class will be a hub class if it inherits from Hub, however A signalR's Hub class can recall the client's js codes as its event by definations of interfaces, A sample is something like this:

  public interface ICall
  {
     void Say(string word);
  }
  public class MyHub: Hub<ICall>
  {
         public void CallSay(string say)
         {
                Context.Caller.Say("Hello"+say);
         }
   }

At the client side, your declaration is:
var myHub = $.connection.hub.myHub;
myHub.server.callSay("Yes"); //This will call SignalR's server-side thing.
myHub.client.say=function(words){alert(words);} //This is an event called by "CallSay" at "MyHub".

From the given example you can see that here interfaces used for the declarations of client's js anoymous event functions. So this must be an interface instead of a class. And If I pass a class inside it, this means the SignalR will execute this at the server-side, and it won't return to activate the client's anoymous js function.

[HaloFour]

Seems to be a pretty limited use case for a language feature. Do you know of any others?

[whoisj]

Interface gives no contract. At least class is used to indicate by-reference. You even need to use new() to enable allocation. I'm very confused as to what this brings, but it sounds interesting so I'd like to understand.

[ghost]

Haha……Yes. To a general thought an interface cannot be used directly. However I only give you an example of SignalR, which means, since net 4.0 starts dynamic object. I mean that if dynamic object begins more and more popular (You see that dynamic objects don't have any intellisenses at all).

However, just like SignalR and if you take some time to see SignalR's core codes, you will find Hub will change dynamic object to something like "interface proxy". This means we define an interface about its declarations of its inner properties, functions……In fact this is a dynamic object type, but it can be used through intellisense. This is my thought from SignalR —— Here "interface" takes the ability of "declarations" (something like WebService's proxy or TypeScript's interface, in fact the real thing doesn't implement it). It just gives Visual Studio and customers intellisenses.

All in all, From SignalR's thought I can see that "interface" can have another very important usage：Interface Declarations For Dynamic Object Type.

[HaloFour]

That was proposed as #3012 , the ability to specify an interface to use with a dynamic object so that you can get some Intellisense support.

[yume-chan]

Recently I'm working on a P/Invoke project and I found another usage.

In COM, lots of classes will uses methods like HRESULT GetService (REFIID riid, void** ppObject) to return some services (Most common is QueryInterface).

So I wrapped it to a generic method:

public T GetService<T>()
{
    Guid iid = type(T).GUID;
    return (T)WrappedObject.GetService(ref iid);
}

Now I want T must be an interface, maybe user will call my method with a wrong interface, but it's better than nothing.

[gafter]

We are now taking language feature discussion on https://github.com/dotnet/csharplang for C# specific issues, https://github.com/dotnet/vblang for VB-specific features, and https://github.com/dotnet/csharplang for features that affect both languages.