Proposal: Allow auto implementing delegated interface

[glatzert]

We encounter the situation that we have to delegate the implementation of interfaces to an private instance of an object implementing the interface:

interface IInterface {
  void myFunc();
  int myOtherFunc();
  //.. my other umpteen methods
}
class MyClass : IInterface {
  private IInterface myInterface;

  public void myFunc() => myInterface.myFunc();
  public int myOtherFunc() { return 42; };

  // more forwards
}

It would be nice to write a shorthand definition like this:

class MyFancyClass : IInterface {
  private **(implicit|explicit)** IInterface myInterface; //define if the interface should be implicitly or explicitly implemented.

  public int myOtherFunc() {
    //it's important to "overwrite" this single interface member
    return 42;
  }
}

[DavidArno]

There are some suggestions around the delegation pattern that were raised via Roslyn issues "back in the day", eg [Proposal] Deligation class and Proposal: C# interface delegation.

Whilst I at least think providing something along these lines would be good, the language team didn't seem very receptive to it in the past.

[gafter]

The default interface implementation proposal can provide one way of implementing this request.

[orthoxerox]

@gafter how? If I have interface IA implemented by class C and I have field C _c in class D that implements the same interface, how will default interface methods help me write several boilerplate methods in D? I understand they will help if I add extra methods to IA later.

[svick]

@orthoxerox I have no idea if this is what @gafter meant, but I think you could do it by creating a second interface IDelegatetedInterface, which declares abstract property Instance and providers default implementation for all methods by delegating to Instance:

public interface IInterface
{
    void MyFunc();
    int MyOtherFunc();
    // my other umpteen methods
}

internal interface IDelegatedInterface : IInterface
{
    IInterface Instance { get; }

    override void MyFunc() => Instance.MyFunc();
    override int MyOtherFunc() => Instance.MyOtherFunc();
    // …
}

public class MyClass : IDelegatedInterface
{
    IInterface IDelegatedInterface.Instance { get; } // auto-property

    public int MyOtherFunc() => 42; // not delegated
}

One issue with this approach is that MyClass.Instance becomes effectively as accessible as IDelegatedInterface (in this case, internal). Maybe this is what protected in interfaces could be used for? (Which is one of the open questions in #288.)

[orthoxerox]

@svick I see. I still have to write this delegation of umpteen methods. The big benefit is that I have to do it only once instead of once per implementing class.

[Thaina]

I was making duplicate idea but difference syntax

My propose is like this

class SafeAddDictionary<K,V> : Dictionary<K,V>
{
    readonly Dictionary<K,V> dict = new Dictionary<K,V>();

    public void Add(K key,V value) // implement only Add
    {
         if(!dict.Contain(key))
              dict.Add(key,value);
    }

    Dictionary<K,V>.this => dict; // syntax to be transpiled
    // Transpiler implement everything except `Add`
}

I think this should be able to do with just transpiling code at compile time

[yringler]

I was also going to make such a proposal, but then saw that #2017 had the syntax I had in mind.

It seems there are a lot of people waking up in the morning and saying "Gosh, I sure wish I could auto-implement interfaces", and going ahead to make (or almost make) yet another proposal for the same feature.

Perhaps that would imply that this is a useful and much desired feature?
Especially considering that it's just "syntactic sugar", I think it is reasonable to consider this sooner, rather than later when #107 is maybe eventually released (I saw that issue referrecened as solving this feature request in one of the billion and 2 requests for this feature, can't remember which).

[CyrusNajmabadi]

I think it is reasonable to consider this sooner, rather than later

Someone on the LDM would have to feel this was worthwhile enough to 'champion'. So far, no one has thought that is the case.

[Joe4evr]

It seems there are a lot of people waking up in the morning and saying "Gosh, I sure wish I could auto-implement interfaces",

And all these people can use the 'Implement interface through [...]' code fix without needing language integration:

[yringler]

One goal of a high level language is to avoid writing stuff that the computer can figure out itself.

For example, c# offers auto-properties (public Id {get; private set;}), even though you could just manually set up a backing field yourself (ala typescript).
And the the whole while/for loop thing can be replaced with goto.
foreach could just use indexing.

The impetus for this feature request (although I can only speak for myself; I haven't done a poll) is not to avoid typing, it's because I don't want that boilerplate code in my class.

Also-

What if there are a bunch of methods/properties on the interface?
What if a class implements a bunch of interfaces through other classes?
What if the interface changes?
What if the interface changes, and there are multiple classes using generated code to delegate the interface?

The answer to all of these questions is: a lot of drugereous and repetitive update work.
Which is not the end of the world, but in general c# is a great language which makes stuff easier, and it would be nice to also have some of that goodness here.

[yringler]

I think it is reasonable to consider this sooner, rather than later

Someone on the LDM would have to feel this was worthwhile enough to 'champion'. So far, no one has thought that is the case.

Yup, too bad. But that can change; people asking for/discussing features they want (without spamming - I tried to avoid that by looking at the open issues and commenting here instead of opening a new issue) are taking part in the design process by drawing attention to desirable features.

If this is actually a good idea, and enough people are talking about it, maybe a 'champion' will take a look again.

[CyrusNajmabadi]

Understood :) I was just letting you know the way this works here. Someone has to champion it.

If this is actually a good idea, and enough people are talking about it, maybe a 'champion' will take a look again.

Yup. That's how it often works. But there are literally hundreds of proposals with thousands of bits of feedback. And that's just here. There are many other avenues where feedback flows to the LDM. In general, they're routinely looking and reassessing things. If this ever makes the cut, they will let you know :)

[AlexVallat]

This could be used to compose multiple interface parts:

interface IFoo
{
  void DoFoo();
}
interface IBar
{
  void DoBar();
}
interface IFoobar : IFoo, IBar
{
  void DoFoobar();
}

class Foobarator : IFoobar
{
  private implicit IFoo myFooer;
  private implicit IBar myBarer;
  public void DoFoobar() {}
}

We could even be wildly optimistic and hope that in the future this may even open the way to inheritance from generic type parameters:

class Foo<T> : T where T: IFoo
{
  public void DoFoo() { }
  private implicit T everythingElse;
}

[avilv]

this has been my #1 pet peeve for years now..

[YairHalberstadt]

You can do this via Source Generators, using something like https://github.com/beakona/AutoInterface

[MatriXcel]

This is seriously cool! Thanks for sharing that.

[AqlaSolutions]

Since source generators don't support chaining, they can't be relied on. The more generators you use, the more problems you have when some features don't work because one generator needs output of another. So having a possibility to do something with generators currently shouldn't be used as an argument against including the feature in the language itself.

[IS4Code]

There have been other syntax suggestions, such as MyClass : IInterface as myInterface or MyClass : IInterface via myInterface. I think it's better to specify the member alongside the interface name, since you know directly how it is implemented (but implicit/explicit is a good addition there too), and it also might be worthwhile to allow this or base instead of a member name.

I think the VS function or a source generator is not enough to address this, because "optimal" solution cannot be expressed in means of C# alone. For example:

struct A : IFormattable
{
    string IFormattable.ToString(string format, IFormatProvider formatProvider) => ...;
}

struct B : IFormattable
{
    A val;

    string IFormattable.ToString(string format, IFormatProvider formatProvider) => ((IFormattable)val).ToString(format, formatProvider);
}

Visual Studio generates this implementation, but it is incorrect! Casting val to IFormattable involves boxing and the implementation is thus no longer called on the original value! This might not matter that much here (though A.ToString could cache the result so this would be detectable) but there are situations where it would be much more noticeable.

To implement this "properly", this code is needed in C#:

string IFormattable.ToString(string format, IFormatProvider formatProvider) => ToStringFormattable(ref val, format, formatProvider);

static string ToStringFormattable<T>(ref T val, string format, IFormatProvider formatProvider) where T : IFormattable
{
  return val.ToString(format, formatProvider);
}

However the compiler could implement it in a more efficient way, without the generic method. In CIL:

constrained. A
callvirt instance string [System.Runtime]System.IFormattable::ToString(string, class [System.Runtime]System.IFormatProvider)

The compiler already generates similar code when calling IDisposable methods. As an alternative, this sort of "calling through base" could be implemented instead (which might also be useful in other situations), like base<IFormattable>(val).ToString(...).