!Lightweight! Default interface members implementation. Primary for backward compatibility of improved BCL interfaces. MINIMAL CLR CHANGES ARE REQUIRED.

[dmitriyse]

---

THIS IS LIGHTWEIGHT SUBSET OF #52
That can be implemented sooner than #52

1. Firstly we adds this limited support
2. Later after CLR improvement we adds Champion "default interface methods" (16.3, Core 3) #52

---

Interfaces can also define standard implementation based on base contracts elements.

public interface IBase
{
     int MyProperty {get;}
     string MyFormatting{get;}
}

public interface IDerived: IBase
{
      // This is just defaults, we can override this in the base class.
      string GetFormattedProperty()
      {
            //We can use any members of a base class and anything from System.Object!!!!
            return string.Format(MyFormatting, MyProperty);
      }
}

public class SomeImpl: IDerived
{
       public int MyProperty {get;} = 5;
       public int MyFormatting {get;} = "MyProperty={0}";

       // --------- Magic Implicit Insert by C# (hope 8.0) compiler---
       string IDerived.GetFormattedProperty()
       {
             var thisCasted = (IDerived)this;
             return string.Format(thisCasted.MyFormatting, thisCasted.MyProperty);
       }
       //------------------------------------------------------------------
}

This feature will:

1. Eliminates tons of boiler-plate code
2. Solve super-strong problem of adding new features to existing BCL contracts, but allowing existing code to not implement new interface members.
   For example with this feature we can easily add IsReadOnly property to IReadOnlyCollection:
   (see proposal https://github.com/dotnet/corefx/issues/16660)

public interface IReadOnlyCollection<T>
{
    bool IsReadOnly{
        get
        {
             // .this is threated by Compiler as an object.
             var mutableCollection = this as ICollection<T>;
             if (mutableCollection == null)
             {
                   throw new NotImplementedException("You should add your implementation.");
             }
             return mutableCollection.IsReadOnly;
        }
    }
}

3. Even more magic !!! with this feature we can finally get ICollection to be inherited from IReadOnlyCollection without breaking changes.
   (https://github.com/dotnet/corefx/issues/16626)

public interface ICollection<T>: IReadOnlyCollection<T>
{
     // no any member should be migrated to IReadOnlyCollection.
     // So we will have ICollection<T>.Count and IRedOnlyCollection<T>.Count.
}

public interface IReadOnlyCollection<T>
{
      // The same property is defined in ICollection<T>.
      // Default impelmentation will save as from breaking changes. 
      // Existing code that explicitly implements only ICollection<T>.Count 
      int Count 
      {
            get
            { 
                   // .this is threated by the compiler as System.Object.
                   var mutableCollection = this as ICollection<T>;
                   if (mutableCollection == null)
                   {
                         throw new NotImplementedException("You should add your implementation.");
                   }
                   return mutableCollection.Count;
            }
      }
}

[DavidArno]

An existing, championed, proposal already exists for this: Champion "default interface methods"

[dmitriyse]

Cool!

[DavidArno]

As I dislike the idea of language features promoting the use of inheritance, much less multiple inheritance, I downvoted that championed proposal. Downvoting this one too, for consistency (nothing personal!).

[dmitriyse]

Please let split this "Champion" into two proposals.

1. Lightweight "Default" interface implementations (this proposal)
2. Full weight interface like class proposal (Champion "default interface methods" (16.3, Core 3) #52)

This proposal does not requires any CLR changes, only C# compiler improvement.
Even if some "lightweight" default implementation requires rocket-engine inside than we can do:

public interface IMyContract
{
    // No any property/method/statics supported here.
    // Saving CLR from changes.

    // This will be injected as explicit implementation by Compiler. CLR will not do anything new.
    public int GetAnswerForEverything()
    {
         return GreatThinker.GiveMeAnwerToEverything();
    }

  
}

public static class GreatThinker
{
      // 42 returner.
      public int GiveMeAnswerToEverything()
      {
          // Artificial intelligence inside.
      }
}

But this #52 proposal turns interfaces to C++ interfaces and bring multiple inheritance hell to C#

[HaloFour]

This proposal doesn't solve the main point of the championed proposal, that is to allow an interface in a separate assembly to add a "default" member without breaking any other compiled assemblies containing classes that implement that interface.

[HaloFour]

The championed proposal renders this proposal entirely obsolete. The implementation is nearly identical, except that the CLR is responsible for wiring up the static default instead of the compiler. I don't see room for both proposals. And considering that the other proposal is actually already "championed" by a member of the C# design team, I can't imagine that they would consider an alternative that solves fewer problems.

[HaloFour]

This proposal doesn't solve that problem. If the BCL were to add new members to existing interfaces all assemblies containing classes implementing those interfaces would fail until they are recompiled. That requirement makes it largely useless.

[dmitriyse]

Yes, unfortunately you are right CLR changes are required even for this proposal.
Thank you for pointing.

[dmitriyse]

And considering that the other proposal is actually already "championed" by a member of the C# design team, I can't imagine that they would consider an alternative that solves fewer problems.

We can close this proposal. It's just implementation stage of #52