dynamic interface Proposal.

[MiddleTommy]

I have always thought duck typing was a feature worth looking at. I understand how it doesn't work well in a typed language and quickly becomes like javascript. The dynamic keyword was the compromise but that looses compiler checking and allows simple type checking errors. I would like to propose a new Feature I call dynamic interfaces:
The syntax would be like this

dynamic interface IFoo{...}

The difference between a standard interface and a dynamic interface is that a dynamic interface never gets implemented. It is mainly used by the compiler and intellisense.

Example:

//From third party library
public class Existing 
{
    public string Bar {get;set;}
}

//From another library
public class Another
{
   public string Bar {get;set;}
}

// your code
public dynamic interface IFoo
{
   string Bar {get;set;}
}

public class Test
{
      public void TestBar(IFoo foo)
      {
              var str = foo.Bar;
              Console.WriteLine($"Bar = {str}");
      }
      public void Test()
      {
              var ex = new Existing();
              TestBar(ex);

              var an = new Another();
              TestBar(an);
      }

}

Where this could really get interesting is with Extension Methods. You could extend objects based on their Methods and Properties instead of their class inheritance.

This also fits nicely with Pattern Matching. It would allow you to pre-define your Pattern with a dynamic interface and then simply use the "is" operator in a switch statement. This would take pattern matching to the next level.

var ex = new Existing();
switch(ex)
{
     case ex is IFoo:
            .....
            break;
}

[HaloFour]

Dupe of #3012 and #5306.

[MiddleTommy]

@HaloFour wow didnt see those
This is similar to #3012
But this has distinct differences. Dynamic interfaces would never be implemented. If they were a compiler error would be thrown that "Cant inherit from a dynamic interface". A dynamic interface would solve the problem in #3102 but it goes much further to other problems.

Also similar to #5306
The Syntax on #5306 would not work with or would be clunky with Pattern Matching. Also #5306 suggests you can use any interface with the dynamic keyword infront of it. My proposal requires you to specify a new "dynamic interface" for a special use. My proposal has simpler syntax. A dynamic interface is more like a Pattern than a dynamic object. you could call it "pattern" instead of "dynamic interface" but that would require a new key word.

I guess one could create a dynamic interface that inherits from a regular interface to save re-typing.

public interface IFoo
{
   string Bar {get;set;}
}

public dynamic interface dIFoo : IFoo {}

[DavidArno]

Duck typing would be a great feature ... but you are asking for it in the wrong place. The CLR would need to support it first for it to work properly, as such type checking is a runtime function as much as a compile-time one.

[HaloFour]

Oh, in that case, #7844.

The problem is awkward runtime support. The C# compiler couldn't affect the actual interfaces implemented by an arbitrary type. The closest the compiler could get is to emit a wrapper class that implements the interface and dispatches the calls to the target instance. But it would be impossible to cast that back to the original target type. To the CLR, the target type could never actually implement that interface. The isinst opcode would always push false and the castclass opcode would certainly throw. With pattern matching, if ex was object the compiler would be forced to emit a series of reflection calls, which would not be particularly performant.

I think that structural typing would be interesting and useful, but without support for it through the CLR, alongside static typing, it wouldn't be a very good experience.

[benaadams]

Could do some possibly horrible code generation expansion and use generics, struct redirection and constrained op code for no allocs

Convert it to something like?

struct DynamicFooExisting : IFoo
{
    Existing _foo;
    string IFoo.Bar
    {
        get { return _foo.Bar; }
        set { _foo.Bar = value; }
    }
    public static implicit operator DynamicFooExisting(Existing foo)
    {
        return new DynamicFooExisting() { _foo = foo };
    }
}
struct DynamicFooAnother : IFoo
{
    Another _foo;
    string IFoo.Bar
    {
        get { return _foo.Bar; }
        set { _foo.Bar = value; }
    }
    public static implicit operator DynamicFooAnother(Another foo)
    {
        return new DynamicFooAnother() { _foo = foo };
    }
}

public void TestBar<T>(T foo) where T : IFoo
{
    var str = foo.Bar;
    Console.WriteLine($"Bar = {str}");
}

public void Test()
{
    var ex = new Existing();
    TestBar((DynamicFooExisting)ex);

    var an = new Another();
    TestBar((DynamicFooAnother)an);
}

Wouldn't work with is though

[HaloFour]

@benaadams Even if the C# did something that awful it wouldn't help how any of the rest of the run time would see the target type or the wrapper type. You'd still be forced to box the wrapper in order to pass it to any arbitrary method expecting an instance of that interface and invocation of any member methods would still have to be through callvirt. The implicit conversion operators would do little to help since the voodoo wouldn't extend to any referenced assemblies.

[benaadams]

@HaloFour the rest of the runtime and reference assemblies wouldn't accept the dynamic interface as they wouldn't even know about it.

If you converted all uses from void TestBar(IFoo foo) to TestBar<T>(T foo) where T : IFoo

And accepted a dynamic interface couldn't be cast to something else; it could all be done compile time.

[HaloFour]

@benaadams

So, the feature couldn't extend beyond your own assembly and it also requires you to make specific concessions as to how you work with these instances? Why aren't you just implementing the interface then?

Not to mention, that type disparity will still exist. Use of is will still fail in your own assembly, as will casts.

Sounds like a lot of work for some really brittle voodoo.

[benaadams]

@HaloFour it would extend to assemblies referencing you, but not assemblies you referenced.

So if I had a method that wanted an object that wrote bytes could have an interface that was

dynamic interface IWriter { void Write(byte[] buffer, int index, int count) }

and anything that used that interface could happily take a Stream, BinaryWriter or BlobWriter even though none of them are derived from each other.

Not being able to cast should be fine as the point is to specify everything you need in the interface. If you need more for a different variant, then inherit the interface and create a new function and go via type overloading rather than if statements. (though should be able to cast up the dynamic interface chain)

[benaadams]

You could even rewrite is and as tests to check a value property on the struct so they worked.

So

dynamic interface IWriter { void Write(byte[] buffer, int index, int count); }

becomes

interface IWriter 
{ 
    void Write(byte[] buffer, int index, int count);
    object Value { get; }
}

And

public void TestBar(IWriter w)
{
    var s = w as Stream;
    if (s != null)
    { 
        ...

becomes

void Test<T>(T w) where T : IWriter
{
    var s = w.Value as Stream;
    if (s != null)
    { 
        ...

[MiddleTommy]

@HaloFour Lack of CLR support is a bummer. Good to know that the idea I've been kicking around for years, others have been thinking of it too. I use only C# so its good to know other languages have this feature already. I hope since other languages do this it could eventually be adopted in the CLR.

Perhaps the only way to get the CLR to consider this support is to have the Roslyn team want it. We need to convince the Roslyn team that this is a killer feature for the upcoming Pattern Matching with a ton of other benefits. Then they would have more pull with the CLR.

[Opiumtm]

@MiddleTommy
CLR does support all you need to implement dynamic interfaces.
On CLR-level dynamic interface may be regular interface annotated by [DynamicInterface] attribute.
Compiler should generate wrappers for any object statically casted as dynamic interface on-demand (at compile time).

If you going to achieve same results in source code - you write similar boilerplate code, simply invoking members of the wrapped object.

It essentially is an application of adapter pattern

public dynamic interface IFoo
{
    string Bar { get; set;}
}

public class Class1
{
    public string Bar { get; set; }
}

public class Class2
{
    public string Bar { get; set; }
}

public static class Test
{
    public static void Test(IFoo src)
    {
        Console.WriteLine(src.Bar);
    }

    public static void Test()
    {
        var c1 = new Class1();
        var c2 = new Class1();
        Test(c1);
        Test(c2);
    }
}

would translate to

[DynamicInterface]  // needed for compiler to distinct between regular and dynamic interfaces
public interface IFoo
{
     string Bar { get; set;}
}    

[DynamicInterfaceWrapper(typeof(IFoo), typeof(Class1))]
internal sealed class DynamicInterfaceWrapper_Class1 : IFoo
{
    private readonly Class1 _wrappedObj;

    public DynamicInterfaceWrapper_Class1(Class1 wrappedObj)
    {
        _wrappedObj = wrappedObj;
    }

    public string Bar
    {
        get
        {
            return wrappedObj.Bar;
        }
        set
        {
            wrappedObj.Bar = value;
        }
    }
}

[DynamicInterfaceWrapper(typeof(IFoo), typeof(Class2))]
internal sealed class DynamicInterfaceWrapper_Class2 : IFoo
{
    private readonly Class2 _wrappedObj;

    public DynamicInterfaceWrapper_Class2(Class2 wrappedObj)
    {
        _wrappedObj = wrappedObj;
    }

    public string Bar
    {
        get
        {
            return wrappedObj.Bar;
        }
        set
        {
            wrappedObj.Bar = value;
        }
    }
}

public static class Test
{
    // Unchanged! As dynamic interface is a regular interface on CLR-level
    public static void Test([DynamicInterface] IFoo src)
    {
        Console.WriteLine(src.Bar);
    }

    public static void Test()
    {
        var c1 = new Class1();
        var c2 = new Class1();
        Test(new DynamicInterfaceWrapper_Class1(c1));
        Test(new DynamicInterfaceWrapper_Class2(c2));
    }
}

So dynamic interface implementation require compiler to generate assembly-wide internal wrapper classes (re-used in same assembly) which simply invoke wrapped object members.
These dynamic interface implementations should be internal and should be re-defined for each assembly (even if same type is wrapped for dynamic interface argument) for type-safety, as compiler is sure about code it compile and can't be sure about infrastructure generated classes in other assemblies.

[kulics]

@gafter @Opiumtm @MiddleTommy
I also really need this feature of the dynamic interface.

I wrote a language for .NET, which simplifies a lot of syntax and hopes to be a .NET tool that is more suitable for getting started.
Xs Lang
One of the most needed features is the dynamic interface, which makes the language syntax simpler and makes it easier to assemble interesting features.

Regardless of whether this proposal has the opportunity to be promoted, at least I have to declare my support for this feature.

E.g:

IFoo <- {
    bar(): Str
}

Class1 -> {
    bar(): Str
}

Class2 -> {
    bar(): Str
}

Test(src: IFoo) -> () {
    Prt(src.bar)
}

Test() -> () {
    c1 := Class1{}
    c2 := Class2{}
    Test(c1)
    Test(c2)
}

[bbarry]

This looks like a duplicate of #164 to me.

[YairHalberstadt]

@bbarry
This proposal was opened 3 years ago in Roslyn, and moved by gafter 14 days ago.

[HaloFour]

I have a feeling that it falls under the umbrella with shapes/type-classes/extension-interfaces/whatever-its-called-today.

@kulics

Does your language transpile to C#? If not I'm not sure how these proposals would benefit your language. You could follow whatever IL generation lead the C# team decides to do, but even if CLR changes end up on the table to help in facilitating this I doubt it will ever be as transparent as just passing some arbitrary reference which does not implement an interface to a method that expects an instance of that interface. I expect the compiler will need to be involved at some level to generate a bridge/witness type.

[kulics]

@HaloFour
I think the dynamic interface is a more suitable name for C#, which does not increase the C# keyword, but also describes its function, which is very suitable.

Regardless of what it is called, it is increasingly a feature that can have a significant impact on C#, and its importance is not lower than the generics of the year.

I sincerely hope that one day I will hear exciting news. Maybe this process has to be promoted by everyone who has this desire.

My language is currently translated to C#, I think it is not ready to translate to IL, it still needs to be grammatically tested, preferably the opinions of C# users.
Although I can implement dynamic interface features inside this language, if C# supports this feature, it will be easier for the two languages to interact, so I also hope that C# can support it.

If you are interested, please feel free to browse the grammar of this language. I will be very happy if I can receive your opinion.

[HaloFour]

@kulics

I think the dynamic interface is a more suitable name for C#, which does not increase the C# keyword, but also describes its function, which is very suitable.

I personally don't think "dynamic interfaces" is the right description as the feature as described isn't about introducing new kinds of interfaces but instead about ways of taking existing interfaces and existing types and defining the extensions that allows that type to appear to implement that interface. "Extension implementation" is probably a better term, although exactly what it's called is a lot less relevant to what it actually does.

I think this is the most recent exploration on the subject: #1711

This is all very early in design, though, so it could go in any direction.

[marksmeltzer]

Is this a very different concept from duck typing? 🤔

[kulics]

@HaloFour
"Extension implementation" are easier to think of as using extensions to make classes implement interfaces.
But the interface design discussed in this topic is closer to the implicit interface of golang or the concept of C++.

In fact, we just want a duck type that supports static checking, no matter what its name is. We want this feature if we want to get the benefits of a duck type without losing the benefits of a strong type.

This may be a trend, more and more people will consider this, I am very concerned about the subsequent development.

[Joe4evr]

In fact, we just want a duck type that supports static checking, no matter what its name is. We want this feature if we want to get the benefits of a duck type without losing the benefits of a strong type.

Then Shapes is 100% what you want and you should keep an eye out for what's gonna happen in that space.

[kulics]

@Joe4evr
Yes, I am also very concerned about it, I hope the C# team can pay attention to our needs.

[HaloFour]

@kulics

"Extension implementation" are easier to think of as using extensions to make classes implement interfaces.

Yes. This is a good thing.

But the interface design discussed in this topic is closer to the implicit interface of golang or the concept of C++.

"Extension implementation" solves both, and has several other distinct advantages.

1. You don't have to define a new type of interface. The feature would work with all existing interfaces and all existing APIs expecting those interfaces. Adding a new "dynamic interface" or "shape" type splits the ecosystem and provides no immediate benefits to users.
2. It makes it much easier to bridge the gap between a type that implements 90% of a given interface via extension members. This is true even if you don't own and can't modify either the interface or the target type.

It's also possible that if the type exposes all of the members needed to implement a given interface that the "witness type" can automatically be created by the compiler, which effectively covers duck typing as well. If the team can enable more scenarios that's something that is definitely in their interest.

[marksmeltzer]

@HaloFour I was reading up on #1711 -- a very fascinating discussion with lots of great ideas. I am not too thrilled about the concept of witness types though, unless they could be implemented as free abstractions. Until we can get the JIT improvements to cast an interface implemented on struct without boxing, I am assuming the witness will need to be allocated.

It is probably worth the trade off even if an allocation is required. However, what's happening there is essentially an automatically generated implementation of a decorator pattern and there will be a bit of a performance trade off due to the extra layer of indirection (two pointers instead of one).

While I have wanted duck typing for a while (which doesn't necessarily require a witness), the concept of being able to attach arbitrary interfaces to existing classes via extensions is a very cool concept -- it does seem to require something like a witness since there could be multiple extensions that apply the same interface with a different implementation. So the witness is required to disambiguate, in principle. So in that case, the witness is basically an implementation of the classic decorator pattern.

I would presume that one could even override a class' default implementation for an interface to use an extension instead with an appropriately configured witness (not sure what the syntax would look like -- maybe the interface extension would be invoked explicitly in that case).

[marksmeltzer]

@kulics to solve the problem for your transpiled language in the meantime, you can just generate decorated classes to take whatever input and implement whatever interface on the decorator and inject the user defined logic into the decorator's interface implementation. Easy peasy. No fundamental changes are needed for C# to pull that off. (You could use the same approach even for emitting LLVM or CLI op code.)

Most language syntax is just a sugary coating around design patterns anyway.

Bonus: depending on your use cases, you may be able to generate struct decorators instead of classes when you can avoid boxing. However, theoretically the JIT will get better about avoiding boxing in that case in the future.

[HaloFour]

@marksmeltzer

Until we can get the JIT improvements to cast an interface implemented on struct without boxing, I am assuming the witness will need to be allocated.

The witness is a struct, so there is no additional allocation. They also only contain pass-through methods to the real members, which are very easily inlined by the JIT. That approach was chosen specifically because it should be a zero-cost abstraction.