Champion "default interface methods" (16.3, Core 3)

[gafter]

• Proposal added: proposals/csharp-8.0/default-interface-methods.md
• Discussed in LDM (2017-03-08, 2017-03-21, 2017-04-05, 2017-04-18, 2017-04-19, 2017-05-31)
• Decision in LDM (prototype in progress)
• Finalized (done, rejected, inactive)
• Spec'ed

Open issues are being tracked at #406

LDM history:

• https://github.com/dotnet/csharplang/blob/master/meetings/2017/LDM-2017-03-08.md
• https://github.com/dotnet/csharplang/blob/master/meetings/2017/LDM-2017-03-21.md
• https://github.com/dotnet/csharplang/blob/master/meetings/2017/LDM-2017-04-05.md
• https://github.com/dotnet/csharplang/blob/master/meetings/2017/LDM-2017-04-11.md
• https://github.com/dotnet/csharplang/blob/master/meetings/2017/LDM-2017-04-18.md
• https://github.com/dotnet/csharplang/blob/master/meetings/2017/LDM-2017-04-19.md
• https://github.com/dotnet/csharplang/blob/master/meetings/2017/LDM-2017-05-17.md
• https://github.com/dotnet/csharplang/blob/master/meetings/2017/LDM-2017-05-31.md
• https://github.com/dotnet/csharplang/blob/master/meetings/2017/LDM-2017-06-14.md
• https://github.com/dotnet/csharplang/blob/master/meetings/2018/LDM-2018-10-17.md
• https://github.com/dotnet/csharplang/blob/master/meetings/2018/LDM-2018-10-17.md#issues-in-default-interface-methods
• https://github.com/dotnet/csharplang/blob/master/meetings/2018/LDM-2018-11-14.md#default-interface-implementations
• https://github.com/dotnet/csharplang/blob/master/meetings/2019/LDM-2019-02-25.md
• https://github.com/dotnet/csharplang/blob/master/meetings/2019/LDM-2019-02-27.md#collision-of-lookup-rules-and-decisions-for-base
• https://github.com/dotnet/csharplang/blob/master/meetings/2019/LDM-2019-03-13.md#interface-reabstraction (reabstraction)
• https://github.com/dotnet/csharplang/blob/master/meetings/2019/LDM-2019-03-27.md#default-interface-methods
• https://github.com/dotnet/csharplang/blob/master/meetings/2019/LDM-2019-04-01.md#revisit-objectmemberwiseclone
• https://github.com/dotnet/csharplang/blob/master/meetings/2019/LDM-2019-04-29.md#default-interface-implementations-and-base-calls (base calls)

[scottdorman]

Why are we limiting to only extend by allowing private and static methods? What about protected as well?

At Summit last year, @MadsTorgersen and I discussed how this could be used in the context of helping to properly implement IDisposable. From what I can remember of the discussion, and by way of a possible actual syntax, how about something like:

public interface IDisposable
{
        bool Disposed { get; protected set; }

        void Dispose() = 
        {
            Dispose(true);
            GC.SuppressFinalize(this);
        };

        protected virtual void Dispose(bool disposing);
}

(Putting this here so it doesn't get lost. Pending the outcome of the question asked on dotnet/roslyn#17054 (comment) I can repost the comment to the right place.)

[DavidArno]

The spec says there are no alternatives, but there is one: the delegation pattern as suggested in Roslyn issues [Proposal] Deligation class and Proposal: C# interface delegation.

In my opinion at least, the delegation pattern has far more merit than default interface methods:

1. It requires no CLR change (it would be a pure syntax sugar language feature),
2. It operates via composition, rather than inheritance, allowing extension of even sealed classes and structs.
3. It avoids introducing multiple inheritance to the C# language.

Should I submit a PR to update the spec to reflect this alternative, or will you do it, @gafter?

[gafter]

@DavidArno Those "alternatives" do not address the principal motivation for the proposal, and are not, therefore, alternatives:

Virtual extension methods enable an API author to add methods to an interface in future versions without breaking source or binary compatibility with existing implementations of that interface.

[gafter]

@scottdorman protected would not make sense, as no class has an interface as its base class. Moreover, a method invoked from a class receiver (even the implicit this) is never an interface method (because a class does not inherit methods from the interfaces it implements). We'd have to reimagine the meaning of protected in some way to make sense of that, and I'd rather not do that before the value of doing so is clear.

[scottdorman]

@gafter I disagree that it doesn't make sense. Take the example of IDisposable. The full pattern is to include the protected virtual void Dispose(bool disposing) method, but since it's not part of the interface (because interfaces can't have protected members) it rarely gets implemented...which means that a lot of disposable classes end up being implemented the wrong way.

a class does not inherit methods from the interfaces it implements

This is true, but isn't this proposal sort of breaking that statement? We're basically saying "Implement this interface but you don't have to provide your own implementation for this interface method because the interface is already giving you one." You can then decide later on to implement the method yourself, in which case the default interface method is effectively ignored/overridden with the actual class implementation.

We'd have to reimagine the meaning of protected in some way

How so? This is simply saying that if you implement this interface there is a protected member that must be implemented. In that respect, it doesn't seem like it's any different than saying "The syntax for an interface is extended to permit private methods (the default access is public)", which is what we have in the proposal now.

[DavidArno]

Those "alternatives" do not address the principal motivation for the proposal, and are not, therefore, alternatives
@gafter,

In that case I'm downvoting this proposal as it:

1. Requires CLR changes
2. Operates via inheritance, rather than composition so cannot be applied to sealed classes and structs.
3. It introduces multiple inheritance to the C# language.

Since the underlying aim of this proposal can be achieved using the non-alternative delegation pattern approach, which doesn't suffer from any of the above problems, this doesn't seem a good proposal.

[scottdorman]

@DavidArno Given my earlier example of providing a default correct implementation of IDisposable.Dispose(), how would that be accomplished using your delegation pattern?

One of the goals of this proposal is:

Virtual extension methods enable an API author to add methods to an interface in future versions without breaking source or binary compatibility with existing implementations of that interface.

How would using your delegation pattern achieve that (in my earlier example) such that existing classes which already implement that member aren't broken but new classes can utilize the default implementation?

Just because a proposal requires CLR changes isn't a reason for it not to be done. If that were the case, there's a lot of language features we've gotten over the last several releases that wouldn't exist.

I don't see how this introduces multiple inheritance to the language. Yes, it provides a solution that other languages use multiple inheritance to solve, but it doesn't change the inheritance rules for C#. A class can still only inherit from a single base class and multiple interfaces.

[scottdorman]

I think Proposal: C# interface delegation is useful, would reduce a lot of boiler plate code that has to be written, and would love to see it in the language; however, I don't think it addresses the ability to provide a default implementation for an interface method or property nor does it extend the interface syntax to allow private methods, static methods, "override" methods (and hopefully protected methods).

[Proposal] Deligation class looks to achieve a similar result, albeit with a much uglier and more confusing (in my opinion) syntax so it wouldn't be able to achieve the goals set out in this proposal either.

[gulshan]

I think interfaces can just be allowed to have an unnamed nested class, that implements the interface. The nested class then can provide all the proposed features. Thus the main interfacing portion will not be polluted.

Also, how does this go with proposed extension everything proposal?

[Thaina]

This actually has alternative with generic extension method

I agree with @DavidArno

The proposal is conflict in itself. The purpose is to create function with concrete logic for interface. If it is concrete logic then it should not be overridden and we should separate some logic to be function that class derived from interface should implemented instead

[iam3yal]

@DavidArno

It introduces multiple inheritance to the C# language.

Well, it's not like we can't mimic this today and I don't think that multiple inheritance is bad per se because as far as I understand things like the diamond problem is going to result an error but I can certainly see that it might open a can of worms. :)

I voted for this because I think it can come in handy at times but I really like to see more love to composition too.

[DavidArno]

@scottdorman,

Given my earlier example of providing a default correct implementation of IDisposable.Dispose(), how would that be accomplished using your delegation pattern?

Since @gafter seems opposed to having protected members in an interface, this could be a moot point.
However, rather than duck the issue with a technicality, I should answer your question. Something like the following could be used:

// built-in types
public interface IDisposable
{
    void Dispose();
}

public class Disposable : IDisposable
{
    private readonly Func<bool> _isDisposeNeeded;
    private readonly Action _dispose;

    public Disposable(Func<bool> isDisposeNeeded, Action dispose)
    {
        _isDisposeNeeded = isDisposeNeeded;
        _dispose = dispose;
    }

    public void Dispose()
    {
        if (_isDisposeNeeded())
        {
            _dispose();
            GC.SuppressFinalize(this);
        }         
    }
}

// my type
internal class MyDisposableType : delegate Disposable
{
    private bool _disposed;

    internal MyDisposableType() : delegate(() => !_disposed, PerformDispose) {}

    private void PerformDispose()
    {
        _disposed = true;
        // etc
    }
}

How would using your delegation pattern achieve that (in my earlier example) such that existing classes which already implement that member aren't broken but new classes can utilize the default implementation?

I wouldn't as that isn't necessary. As @Thaina says, this can already be achieved with extension methods.