Anonymous Interface Objects

[khalidabuhakmeh]

Anonymous Interface Objects

• Proposed
• Prototype: Not Started
• Implementation: Not Started
• Specification: Not Started

Summary

Give C# developers the ability to instantiate anonymous objects that implement a specific interface without first implementing a concrete type.

Motivation

In scenarios where developers need to stub a type for unit tests, it becomes increasingly tedious to create classes that are essentially throw away. They add to the complexity of the project and ultimately increase the noise/signal ratio.

Detailed design

public interface IClient
{
    string Name { get; }
}

// single interface
var client = new IClient {
    Name = "Khalid"
};

We can also implement multiple interfaces on an anonymous type.

public interface IClient
{
    string Name { get; }
}

public interface ICustomer
{
    string AccountNumber { get; }
}

// multiple interface
var client = new IClient, ICustomer {
    Name = "Khalid",
    AccountNumber = "8675309"
};

Method implementations can be implemented using lambda methods.

public interface ICashier
{
    decimal CheckOut(Cart cart);
}

var cashier = new ICashier {
   CheckOut = (c) => cart.Total() * 0.2d;
}

Drawbacks

• There are ways to address this issue already in the C# language that requires reflection.

Alternatives

Create stub types for every new scenario you need an interface.

Use Kotlin. Here is a working example where the khalid instance is an anonymous object that happens to implement the IGreeting interface.

    interface IGreeting {
        val name: String
    }

    class Default(override val name: String) : IGreeting

    fun main() {

        val csharp = Default("C# Developer")
        // an anonymous object
        // that implements IGreeting
        val khalid = object: IGreeting {
            override val name: String
                get() = "Khalid (You're Awesome)"
        }

        var folks = listOf(csharp, khalid)
        folks.forEach { println("Hello ${it.name}!") }
    }

Unresolved questions

• What is the behavior when interfaces have conflicting properties/methods?
• Can you define explicit interface implementations?

Design meetings

[jnm2]

Previously discussed at #738 (see HaloFour's comment too)

Unfortunately the first time this was proposed (dotnet/roslyn#13 (comment)):

We have no expectation of ever doing anything like this.

For the record, that comment has 47 downvotes, including mine. I would love this feature.

The alternatives section could mention Moq and NSubstitute. (I like NSubstitute better because it has less ceremony.) NSubstitute is really not a bad way to build up just the parts of the interface you care about for the test, and there would still be times I would prefer NSubstitute over anonymous interface implementation. But I also want this feature in non-test scenarios.

[HaloFour]

See also:

#2517
#4148

[JasonBock]

I would personally want to see the C# team work on other features, like making the type system more expressive and extensible (concepts or roles or whatever it ends up being called :) ). This is something that arguably mocking frameworks can already do (and it doesn't require Reflection either. My recent update to Rocks moved everything to being source generator based), or use source generators to accomplish something very similar (e.g. https://github.com/devlooped/avatar).

[HaloFour]

I disagree that mocking frameworks are a replacement for this feature anymore than manually writing an adapter would be. They are simply not capable or expressive enough and would generally require substantially more code at the call site. A source generator provided adapter could not enclose the state within the method in which the adapter is used, like an anonymous implementation would.

As for the question of priority, that's up to the team, but championing an issue does not establish its priority or precedence over other features. I'd also argue that this feature is substantially less complicated than concepts/roles/shapes/whatever and has absolutely no runtime requirements and could be implemented in a relatively short amount of time, especially since the compiler is already quite capable of producing unnamed display classes for the sake of implementing closures today.

[JasonBock]

Yes, this feature would be less complicated than concepts/roles/shapes/etc. It would still require work, and FWIW there are ways to already achieves the end result. They're not as elegant as what this feature would provide, but again, is it worth it.

I should be clear, I'm not saying "dismiss the idea entirely".

[dstarkowski]

Unit tests are imo one of the most neglected areas in the language. I don't recall any feature in last few versions of C# that was targeted specifically to make unit tests or mocking easier.

Hard to convince someone to write tests, if the test is more complex and obscure than the actual code. Any investment here would be greatly appreciated.

[GalaxiaGuy]

I just like to highlight one use for this that is nothing to do with unit testing (and nothing to do with mocking conceptually, even if a mocking framework might solve the technical issue) is one that HaloFour mentioned (a little too subtley):

Improved interop with Java: #2517

Working with Xamarin Android, I write code every few days that could take advantage of this.

[fa1ntl1ght]

I think there should also be a way to specify is it a class or a struct
And wouldn't it be better if it wasn't limited to just interfaces?
Why not allow any type declarations be inlined into new()?

P.S. Not literally "any", of course. E.g. you cannot use anonymous enums etc. But at least, anonymous classes inheriting normal classes can be done.

[Phantonia]

@0x0737 Do you mean that one should be able to specify if the anonymous type should be generated as a class or struct? I don't think generating it as a struct would have any advantages due to it being boxed (so heap allocated) anyway because it could only be used via the interface.

[fa1ntl1ght]

@Phantonia I meant I think there is no need to restrict this proposal to anonymous interfaces only. I think it is better to allow to define a local type and create instances of it, something like java's anonymous classes.
This is very useful for unit testing.

Something like this:

ClassA obj = new class : ClassA()
{
    public override void SomeMethod() { /*some code*/ }
};

or with extracted declaration

class ClassB : ClassA
{
    public override void SomeMethod() { /*some code*/ }
}

ClassB obj = new();

[leandromoh]

F# has this feature long time... it is called object expressions

[quixoticaxis]

F# has this feature long time... it is called object expressions

Yeah, and the same-ish syntax would look fine in C#. I had the question why it's not possible in C# from my first day with F#.

[FANMixco]

This will also simplify Android for .NET development in the long term. I have migrated 10 libs and it's a headache because we don't have a similar feature.

[leandromoh]

C# recent features are trying to remove boilerplate code (e.g., top-level statements, records, target-typed new expressions, null-coalescing assignment, etc) so this one would be VERY useful too...

[acaly]

Came from another discussion which let me think about inlining of delegates. Currently it seems (please correct me if I'm wrong) the runtime cannot inline any closure passed into Linq methods, so if there is a hot spot in the Linq method's loop, and the closure is simple enough, then we are paying much to function call overhead. The only way to force inlining (according to sharplab.io) is to use struct implementation of interface like this:

    private interface IAddInt
    {
        int Invoke(int a, int b);
    }
    
    private struct CAddInt : IAddInt
    {
        [MethodImpl(MethodImplOptions.AggressiveInlining)]
        public int Invoke(int a, int b)
        {
            return a + b;
        }
    }
    
    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    private static int M1<T>(int[] a, T closure) where T : struct, IAddInt
    {
        return closure.Invoke(100, a[0]);
    }
    
    public static int M2(int[] a)
    {
        return M2<CAddInt>(a, default); //Here everything will be perfectly inlined and no function call is involved.
    }

This is basically how C++ handles lambda expressions. Since C# already supports lambda in a different way, I think the above code can really benefit from the anonymous interface implementation feature instead. For example, we could write:

    private interface delegate int AddIntDelegate(int a, int b);
    
    private static int M1<T>(int[] a, T d) where T : AddIntDelegate
    {
        return d(a[0], 100);
    }

    public static int M2(int[] a)
    {
        return M1(a, (x, y) => x + y); //The compiler will generate a struct implementing AddIntDelegate
        //or alternatively,
        //return M1(a, new struct { int Invoke(x, y) => x + y; });
    }

Here more than one feature is needed for C# to support it like this (if ever). Not necessarily, the opaque parameter feature (currently as rejected) would also help to make the code looks nearly identical (and being equally powerful) to C++ lambda:

    private interface delegate int AddIntDelegate(int a, int b);
    
    private static int M1(int[] a, some AddIntDelegate d)
    {
        return d(a[0], 100);
    }

    public static int M2(int[] a)
    {
        return M1(a, (x, y) => x + y);
    }