Proposal: Allow delegates to implement single method interfaces

[ThadHouse]

I noticed that https://github.com/dotnet/coreclr/issues/6934 exists, but there is nothing in this repo about that. I could definitely see this being a cool and useful feature. It looks like it would even be supported today by the current clr.

Currently, I have a good amount of libraries where I provide both an interface and Action for running callbacks. This means I have to have 2 entry points for each type of callback. If a delegate could implement the interface, I would only need a single entry point.

It could also enable some interesting uses, especially around IDisposable, as you could create in theory a semi-inline disposable without the need to build a special class to do so.

[svick]

Currently, I have a good amount of libraries where I provide both an interface and Action for running callbacks. This means I have to have 2 entry points for each type of callback. If a delegate could implement the interface, I would only need a single entry point.

Why? What's the point of accepting an interface when any caller with a method can just use method group conversion (or a lambda, if they don't know about method group conversions) to get a delegate?

Also, should lambdas be somehow convertible to interfaces, to make code like this work?

public void MethodWithCallback(ICallbackInterface callback) { … }

…

MethodWithCallback(() => DoSomething());

Or would you have to write the following?

MethodWithCallback(new CallbackInterfaceDelegate(() => DoSomething()));

It could also enable some interesting uses, especially around IDisposable, as you could create in theory a semi-inline disposable without the need to build a special class to do so.

Are you talking about something like the following? (Where DisposableAction is a delegate type that implements IDisposable.)

using (new DisposableAction(() => DoSomething()))
{
    …
}

How is that better than what you can do today?

using (Disposable.Create(() => DoSomething()))
{
    …
}

---

I'm not against this proposal, but the justification presented here sounds weak to me. The one in https://github.com/dotnet/coreclr/issues/6934 (avoiding allocations) makes more sense to me.

[ThadHouse]

Avoiding allocations is definitely a valid use case as well.

In the coreclr example, since Delegate would just implement the interface, it seems like you would just get lambda to interface for free.

[jnm2]

Looks like everyone has one of these 😆

On.Dispose(() => DoSomething(x)) or On.Dispose(cancellationTokenSource.Cancel) etc.

[jnm2]

The desire for this feature has crossed my mind many times, and yet I'm stuck on two things:

• How does the compiler implement this- generate wrapper classes? How does object obj = new Action(foo); ((IDisposable)obj).Dispose(); work, doesn't that need CLR support?
• Won't it be too easy for things that are very semantically different to be mistaken for each other? How far does this go, can I implicitly convert IDisposable to any other interface with a single method matching the signature?

[ThadHouse]

If you look at https://github.com/dotnet/coreclr/issues/6934, The Delegate class can just directly implement the interface. Therefore, there would be no need for any CLR support.

The lambda support is a little harder, but just making delegates implement an interface would be fairly simple. I think something like a lambda would need to be implicitly convertable, but I also think that would require CLR support.

[jnm2]

Oh, a custom class deriving from Delegate. So we will be emitting hidden adapter classes.

[yaakov-h]

@jnm2 we already do, if my understanding of delegates and IL is correct. We'd just need to make that MulticastDelegate subclass also implement the interface with a single method.

[jnm2]

Yes.

Another example would be IProgress.

[jnm2]

Hey, so if you have a logger interface and all the methods have default implementations except one, the delegate would still be able to implement the interface just fine. 😆

[HaloFour]

So is this proposal about explicitly writing a delegate that implements an interface, or is it about having the compiler emit a delegate that implements the interface in order to support lambda syntax et al with such interfaces?

Hey, so if you have a logger interface and all the methods have default implementations except one, the delegate would still be able to implement the interface just fine. 😆

That's how functional interfaces work in Java. You can use lambda syntax as long as they have exactly one required method. But they can have any number of default methods.

[yaakov-h]

This proposal doesn't actually propose anything, but the original coreclr issue seems to be the former, explicitly writing a delegate that implements an interface.

The latter would be neat, too.

[brian-reichle]

For the case of using a lambda expression to provide an interface implementation, the delegate itself is kinda superfluous. Why not just implement the interface on a/the closure object? Though, personally, I would rather extend the anonymous class syntax.

public IDisposable Magic()
{
    return new { void Dispose() => DoSomething(); };
}

Also, if something like this got in, the first thing I would do is write an analyzer rule to forbid it's use in a using clause and direct people towards a try-finally clause instead.

[Opiumtm]

It would be better to support true local interface implementations, as it's supported in Java.

public interface ISomething
{
    void Do(int arg);
    void Do2(int arg1, int arg2);
}

void SomeMethod()
{
    ISomething a;
    Func<int, ISomething> factory;

    int result = 0;

    // "Anonymous" interface implementation
    // Same syntax as for anonymous types, but as it's assigned to interface variable,
    // compiler "know" what methods anonymous type should implement
    a = new {
        void Do(int arg) {
            // you shouldn't declare method as public
            result = arg; // result variable is captured as closure!
        }
        void Do2(int arg1, int arg2) {    
            result = arg1 + arg2; // result variable is captured as closure!
        }
    };    

    // Factory function. Anonymous interface implementation can be declared as lambda-function
    factory = (x) => new {
        void Do(int arg) {
            result = arg + x; // x lambda argument is presented as hidden field in anonymous class
        }
        void Do2(int arg1, int arg2) {    
            result = arg1 + arg2 + x; // x lambda argument is presented as hidden field in anonymous class
        }
    };

    a = x(5);

    // "Local" interface implementation inside method code
    class LocalImplementation : ISomething
    {
        void Do(int arg) {    
            result = arg; // result variable is captured as closure!
        }
        void Do2(int arg1, int arg2) {    
            result = arg1 + arg2; // result variable is captured as closure!
        }
    }

    a = new LocalImplementation();
}

[HaloFour]

@Opiumtm

That would be a separate proposal.

The LDM has already weighed in on that idea on the Roslyn repo, though: dotnet/roslyn#13

[Opiumtm]

@HaloFour
done #738

[jnm2]

I gotta agree with @Opiumtm on this. I'd much rather see #738 (dotnet/roslyn#13) than this if I had to pick.

[nehmebilal]

I think allowing delegates to implement single method interfaces would be mainly useful for readability. In fact, many developers choose to use Func<> or delegates instead of a single method interface because they find it hard to create a class for every use case they want to cover.

For example, I see a lot of code where constructors take a Func<T, IFoo> instead of an IFooFactory. I've even seen people registering the Func<T, IFoo> in their DI containers so that they can be injected in consuming classes. This can lead to confusion because Func<T, IFoo> it's not always obviously an IFoo factory. If single method interfaces can be implemented with delegates, people would more likely choose to use an IFooFactory instead of Func<T, IFoo>, i.e. C# code would be more readable :)

[alrz]

How about the other way around?

interface IInvokable { void Invoke(); }
IInvokable  Method() => () => {};

[svick]

@nehmebilal If those people don't create a custom delegate type now, what makes you think they would create a custom interface type if they could use a lambda to implement it?

@alrz How is that different from a delegate?

[nehmebilal]

@svick This feature is supported in Java and frequently used. It's also often used in public Apis where a single method interface is a parameter that can be replaced with a lambda expression. That said, I agree that the use of custom delegates seems like a reasonable alternative.

Another similar feature that is popular in Java and lacking in C# is inline implementation of an interface (very commonly used in Android apps).

[Joe4evr]

@nehmebilal

Another similar feature that is popular in Java and lacking in C# is inline implementation of an interface

Already suggested at #738.

[HaloFour]

@nehmebilal

This feature is supported in Java and frequently used. It's also often used in public Apis where a single method interface is a parameter that can be replaced with a lambda expression.

Java chose "functional interfaces" as the mechanism through which lambdas work and there is no other way to use them. So it's not like Java elected to support these interfaces on top of something more akin to function pointers or that they've become a common convention despite other ways to accomplish the same goal; they are the only way to do functional programming in Java.

Sometimes there are APIs in .NET where a feature like this would be useful. For example, when a method accepts an IComparer and has no overloads accepting a Comparison delegate. I'm not opposed to blurring the line between delegates and "functional interfaces" in the C# language where lambdas are concerned.

[aluanhaddad]

I'd like to see something akin to #738 but using it to implement single method interfaces seems like it would become an poor and unfortunately common practice.

Needing to pass an IComparer<T> instead of Comparison<T> or Func<T, T, int> seems like an API level concern.

[nehmebilal]

@aluanhaddad It should be as simple as

IComparer myComparer = (x, y) => {// implementation}

Why would that be a poor practice?

Func's are difficult to read and do not integrate well with dependency injection (you can't register more than one Func with a given signature in a container). I'd definitely choose delegates over Funcs.

Programming languages drive APIs and successful APIs make languages successful.

[aluanhaddad]

@nehmebilal it should be as simple as

Comparison<T> myComparison = (x, y) => // implementation.

[HaloFour]

@aluanhaddad

Needing to pass an IComparer<T> instead of Comparison<T> or Func<T, T, int> seems like an API level concern.

Only in the sense that anytime an API exposes one it should also expose overloads that accepts the other. But many APIs don't do this which puts the onus of wrapping the lambda on the consumer of that API. And it is kind of silly because both Comparison<T> and IComparer<T> both describe the exact same kind of operation just wrapped in slightly different clothing.

[Rekkonnect]

Looks like everyone has one of these 😆

Evaluating that code it looks like delegates could support having method members and implementing interfaces, while having access to delegate internals like the call list, the method signature that it accepts, etc.

The above code could be written as something like:

    private delegate void OnDisposeAction() : IDisposable
    {
        private bool disposed = false;

        // Maybe Lazy is overkill
        private Lazy<Action?> action = new(GetAction);
        private Action? Action => action.Value;

        public void Dispose()
        {
            bool wasDisposed = Interlocked.Exchange(ref disposed, true);
            if (wasDisposed)
                return;
            action?.Invoke();
        }

        private Action? GetAction() => GetInvocationList().FirstOrDefault();
    }

It wouldn't guarantee immutability like the custom class that is implemented, and that area would also need some attention, but it's closer to what the delegate's purpose is.