Feature Request - Dynamic Interface for DLR (Dynamic Language Runtime)

[ackava]

Dynamic keyword allows us to access members without implementing a known interface and without knowing type (For use in DLR - Dynamic Language Runtime). Pretty much like how TypeScript uses interface.

But it leads to many issues when member names are named inconsistently and very difficult to enforce any naming convention.

class A {
   public string Name {get;set;}
}

public void Process(dynamic a) {
    a.name ... // no intellisense here !! 
    // also this will not work as n is small
}

// no compilation warning while calling method
A a = new ....
Process(a);

Dynamic Interface, dynamic interface does not exist at runtime, it only assists compiler to detect possible errors and warn. Anyone trying to implement dynamically marked interface will get an error that it is not possible.

// This is dynamic interface
public dynamic interface INamedClass {
    string Name {get;set;}
}

class A {
    public string Name {get;set;}
}

class B {
    public string name {get;set;}
}

// note nc is dynamic, it is not an classic c# interface
public void Process( INamedClass nc) {
    nc.name // compilation error
    nc.Name // correct.. // also intellisense is available
}


A a;
B b;

Process(a); // correct...

Process(b); // compilation error

Benefits

1. Intellisense
2. Compilation error for known interfaces
3. There is no need to change anything at runtime, it is only compilation step that does type/member checking

Overhead

1. Marking dynamic interface with some metadata to assist compilation
2. Otherwise, there can be a system level interface like IDynamicObject and any interface derived from it will serve as dynamic interface.

[svick]

Very similar proposal: #2290.

[ackava]

@svick Similar but Purpose here is different.

[HaloFour]

This falls into the body of work that the team is already exploring for more structural-based typing and extensions:

#1711
#192
#164
#110

[ackava]

@HaloFour I tried looking at each interface, I don't understand how extensions or roles will solve this problem? None of these issues talk about dynamic keyword, none of them reference DLR (Dynamic Language Runtime). It is totally different.

[HaloFour]

@ackava

They have nothing to do with the DLR or dynamic. They have to do with taking a type that doesn't implement an interface and allowing it to do.

Your proposal doesn't seem to have much to do with dynamic either. You want a nominal type of members that the compiler enforces a target type conform to and you want consumption of that type to be further enforced by the compiler by only those members. That's pretty much the exact opposite of what dynamic is intended to do.

You're looking to have A automatically fit into INamedClass with compiler enforcement. That is the role of something like concepts, typeclasses or shapes, and exactly what the proposals I listed are looking to enable.

[gafter]

Is this what you are looking for: https://github.com/ekonbenefits/impromptu-interface

[yaakov-h]

Isn't this just shapes from #192?

[ackava]

@HaloFour What if the type is not inside the current assembly, it is already a type defined somewhere else. How would you implement without using DLR? Will role allow us to assign enforcement to an external type?

[HaloFour]

@ackava

What if the type is not inside the current assembly, it is already a type defined somewhere else. How would you implement without using DLR? Will role allow us to assign enforcement to an external type?

Those kinds of details are still being worked out, but the initial "shapes" proposal would emit a "witness struct" which would serve to bridge between the interface and the target type. That struct would either directly call matching members on the target instance or would bind to compatible extension members, both of which would be resolved at compile time. In the "shapes" proposal the consumer of the shape interface would be generic with the implementation constrained to the interface and struct using constrained calls which would avoid boxing allocations and the simple witness methods would encourage inlining by the runtime.

[ackava]

@HaloFour

both of which would be resolved at compile time

This is exactly what I do not want, that is the whole purpose of dynamic language runtime, and that is why I mentioned dynamic language runtime again and again. You don't seem to understand the problem. If assembly is loaded on runtime, or compiled dynamically, how can we expect it to resolve at compile time?

[FiniteReality]

@HaloFour

both of which would be resolved at compile time

This is exactly what I do not want, that is the whole purpose of dynamic language runtime, and that is why I mentioned dynamic language runtime again and again. You don't seem to understand the problem. If assembly is loaded on runtime, or compiled dynamically, how can we expect it to resolve at compile time?

Then the DLR will emit a class which they can be resolved against. That's how it works internally.