Anonymous and local interface/abstract types implementations

[Opiumtm]

It would be good to support true local interface (or abstract types) 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();
}

[CyrusNajmabadi]

This looks like a dupe of dotnet/roslyn#13 Is there a difference here between this proposal and that one?

[HaloFour]

@CyrusNajmabadi

Worth tracking here anyway since this repo now relates to language changes?

I do think that anonymous and/or local implementations would be a nice feature and it's something that I use frequently enough in Java. Delegates/lambdas are great but can only represent a single action. If I'm building out the implementation of a fluent API it just adds to the boilerplate to then have to define a nested type and manually capture the appropriate data.

For the anonymous implementation I'd much prefer the Java-style syntax where the type being instantiated is the interface name:

var a = new ISomething {
    void Do(int arg) { ... }
    void Do2(int arg1, int arg2) { ... }
};

Of course going down this path opens numerous cans of worms, such as solving scope resolution (ParentClass.this), other nested members, initializers, constructors, whether it can be used to anonymously derive from any arbitrary type, etc.

[jnm2]

@CyrusNajmabadi It's such a juicy and immediately useful feature that I still can't believe you aren't the first to champion it. So weird.

[CyrusNajmabadi]

:) It's very uninteresting to me (and i came from a Java background).

[Opiumtm]

@HaloFour I agree that java-like syntax is better. And, of course, it's make things more clear (you see what interface was implemented). But I think, it should be optional. Explicit interfere declaration can be omitted if left part of assignment isn't var, but a well-known type.

solving scope resolution (ParentClass.this)

this should always reference to anonymous/local implementation (i.e. to the class where method is declared). Reason: it doesn't break existing code in case of copy/paste or refactorings. this of outer class could be captured as closure if you write var parentObj = this; at the outer method scope. It's very easy to capture outer class instance that way.

other nested members

Declared anonymous/local class should always "win" in case of any ambiguity. Reason same as above - to minimize compiler errors after you do copy/paste. And you would do copy/paste when you would convert internal or private nested class to local/anonymous.

initializers

Should be allowed as in regular classes - i.e. you can declare default property value as you do in regular class. Developer also can "initialize" property values with values from captured closures.

var v = "test string";

IInterface a = new {
    string StringProperty { get; set;} = v; // we set up default value from captured closure
}

constructors

Anonymous class should have only parameterless constructor. Constructors with parameters shouldn't be allowed. Compiler would emit constructor with parameters behind the scene (to pass closure object and lambda parameters from factory function), but it's implementation details that developer should not know. Developer should be allowed to create only parameterless constructor. If base class (in the case of anonymous implementation of abstract class) haven't parameterless constructor, developer could pass captured closure values or lambda parameters to base class constructor. Compiler would care of correct values passing.

var v = "value";

AbstractParent a = new {
    this() // use "this" keyword for constructor name
      :base(v) // pass captured value to base class constructor
    { 
    }
};

whether it can be used to anonymously derive from any arbitrary type

Definitely yes! Anonymous implementation is the equivalent of private nested class. Just with captured closures and mangled compiler-generated type name.

[DavidArno]

I can see two use-cases for this:

1. It replaces the need to declare a private type in one part of a file and reference it in another. Effectively, it's that type declaration and usage all rolled into one.
2. It solves that age-old problem of creating an anonymous type in eg a linq expression, and then using that type elsewhere in the code. The following:

var result = from thing in things
             where thing.Foo == 1
             select new { thing.Bar, thing.Baz };

Becomes:

var result = from thing in things
             where thing.Foo == 1
             select new IThing { thing.Bar, thing.Baz };

and now result is an IThing and can easily be passed around one's code.

[Opiumtm]

@DavidArno one major benefit of local/anonymous classes is closure support. It can save lots of lines of code. Built-in ability to get and update local variables values without even single additional line of code. Closures is major reason why lambda functions and local functions are so powerful. It's natural to reuse same power with anonymous/local classes.

[alrz]

I think local type declarations are more appropriate here,

IFoo M() {
  class Local : IFoo { .. }
  return new Local();
}

pros: needs a lot less syntax changes, supports closures, attributes, etc. more readable overall.
cons: not anonymous.

PS: This new IThing { thing.Bar, thing.Baz }; is entirely something else though. it should have been:

new IThing {
  public Bar Bar => thing.Bar;
  public Baz Baz => thing.Baz;
};

[DavidArno]

PS: This new IThing { thing.Bar, thing.Baz }; is entirely something else though. it should have been:

I'd see it as a mashup of existing anonymous type features and what's proposed in the OP.

For the line:

var x = new { thing.Bar, thing.Baz };

The resultant anonymous type has Bar and Baz properties.

So for the line:

var x = new IThing { thing.Bar, thing.Baz };

Then, as long as the signature of IThing matches, eg:

public interface IThing
{
    Bar Bar { get; }
    Baz Baz { get; }
}

then the anonymous type can implement that interface. This could then be extended by the ideas in this proposal, eg if IThing were:

public interface IThing
{
    Bar Bar { get; }
    Baz Baz { get; }
    int Do(int index);
}

Then the type declaration could be:

var x = new IThing 
        { 
            thing.Bar, 
            thing.Baz;
            int Do(int index) => Bar[index];
        };

And if the properties don't match, then the usual anonymous type property matching can be used:

var x = new IThing 
        { 
            Bar = someOtherThing.FooBar, 
            Baz = someOtherThing.FooBaz;
            int Do(int index) => Bar[index];
        };

[jnm2]

Local types would mollify me.

[tuespetre]

I have long wanted something like this; I agree with @HaloFour and @DavidArno's sketches that the instantiation should include the interface type's identifier, e.g. var foo = new IFoo { ... } rather than IFoo foo = new { ... }

[Opiumtm]

@tuespetre
I propose local types for that.

    // "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!
        }
    }

Sometimes it's excessive to declare interface explicitly when left side of assignment is well-known.

ISomeInterface a = new {
  // interface members
}

-- for example

Of course, you can write new Func<int, int>(x => x*x) instead of just x => x*x when function type on left side is well-known and there is no ambiguity. But it's pointless in most cases.

Let's give developer freedom to choose when explicitly declare interface/base class type of anonymous implementation and when omit it.

[DavidArno]

@tuespetre,

At the risk of appearing contrary, I should point out that I'd be happy with either syntax (ideally both):

var foo = new IFoo { ... }
IFoo foo = new { ... }

I just tend to use var ... so would naturally gravitate to the first version, but I can see benefits to the latter syntax too.

[tuespetre]

Good points.

Maybe there is some interplay with the shapes proposal to be considered here too. 🤔

[Joe4evr]

I could swear I commented about this, but maybe I just forgot to click the button.

Anyway, IFoo foo = new { ... } as a syntax option would come naturally if/when #100 gets implemented. So by elimination, var foo = new IFoo { ... } should be the one to get the primary focus for this feature.

[tuespetre]

@Joe4evr oh, nice! I hadn't looked at that one yet.

[Thaina]

I support this but wonder if it need to belong in this repo or roslyn?

[FANMixco]

I hope this will be implemented soon. This is highly important for proper Android support.

[jnm2]

A slightly different proposal by @tmat is at #6049.

[lycc193]

Hi all,
This discussion hasn’t had updates since 2022, but the related Issue #4301 saw activity in late 2024 before being closed. Now that we’re in 2025, are there any new developments or plans here?

[FANMixco]

Hi all, This discussion hasn’t had updates since 2022, but the related Issue #4301 saw activity in late 2024 before being closed. Now that we’re in 2025, are there any new developments or plans here?

Closed as not planned

#4301

The .NET Team doesn't think it's important. Maybe @333fred could tell us more about it since he closed it.

[333fred]

As commented on that issue:

Closing as a duplicate of #738.