Proposal: Non-boxing default-interface methods

[Copilot]

This PR adds a proposal document for non-boxing default-interface methods based on issue #9969.

Summary

Introduce a syntax for declaring default interface methods that avoid boxing when implemented by value types. This is achieved by using a this modifier on interface members, which provides an implicit receiver typed as the implementing type, enabling non-boxing invocation on structs.

Proposed syntax

interface ICounter
{
    int Count { get; set; }
    
    this void Increment() => Count++;
}

Key design decisions

• Simple this modifier: The this modifier indicates the member has an implicit receiver typed as the implementing type
• Anonymous type parameter in lowering: The receiver is an anonymous type parameter constrained to the containing interface (implementation detail of lowering)
• By-ref parameter: The receiver is passed by reference
• Instance method semantics: this members are treated as instance methods on the interface for lookup/invocation, while lowering to static virtual methods
• Receiver handling: All receivers are passed by reference
  • For structs, this avoids boxing
  • For classes, the caller passes a reference to a temporary local copy of the reference variable

Lowering

The this modifier lowers to static virtual methods with an anonymous type parameter and by-ref receiver:

static virtual void Increment<TSelf>(ref TSelf @this) where TSelf : ICounter => @this.Count++;

Original prompt

Please create a proposal PR based on the summary of this issue, in particular the proposed syntax and then the lowering.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[agocke]

@copilot Let's use the same ICounter definition for this example

[Copilot]

Updated in 402dd79 - the Syntax section now uses ICounter with Count property and Increment method to match the Motivation section example.

[agocke]

@copilot Please use the ICounter example in this whole file instead of IFace

[Copilot]

Done in ea54517 - replaced all IFace examples with ICounter throughout the file.

[agocke]

@copilot Actually I think we can simplify this proposal. Since we already marking the methods with this, why not remove the receiver parameter and make it implict, just like in regular instance methods. We can also remove static. But we still need the TSelf type parameter. The requirement should be that it must be the first type parameter on the type and it must have a recursive constraint.

[Copilot]

Done in b0ec6e8 - simplified the proposal to use just this modifier with implicit receiver. Key changes:

• Removed static keyword
• Made receiver parameter implicit (like regular instance methods)
• Added "Type parameter requirements" section: TSelf must be the first type parameter with a recursive constraint

New syntax:

interface ICounter<TSelf> where TSelf : ICounter<TSelf>
{
    this void Increment() => Count++;
}

[agocke]

@copilot technically, the type parameter is not required to be constrained to a struct, therefore all receivers are passed by reference. However, if the type parameter is a class, the caller should create a temporary local copy to avoid mutating the argument.

[Copilot]

Updated in b7ff24d - clarified that all receivers are passed by reference. For classes, the caller passes a reference to a temporary local copy of the reference variable (to avoid mutating the caller's variable if the method reassigns this). Also removed the "Class support" open question since this is now addressed.

[agocke]

@copilot I actually don’t think the type parameter at the type level is necessary. Instead let’s use a type parameter on the method itself (for the receiver).

[Copilot]

Done in 76ad9e2 - changed the proposal to use a method-level type parameter instead of interface-level. The new syntax is this<TSelf> on each member:

interface ICounter
{
    int Count { get; set; }
    
    this<TSelf> void Increment() where TSelf : ICounter => Count++;
}

struct Counter : ICounter
{
    public int Count { get; set; }
}

The interface no longer needs to be generic. The type parameter is declared on the method itself and must be constrained to the containing interface.

[agocke]

@copilot no you can keep the same ‘this’ modifier. We’re just going to change the lowering

[Copilot]

Done in 5438aef - reverted to the simple this modifier. The method-level type parameter is now an implementation detail of the lowering only, not visible in source syntax.

New syntax:

interface ICounter
{
    this void Increment() => Count++;
}

Lowered form (compiler-generated):

static virtual void Increment<TSelf>(ref TSelf @this) where TSelf : ICounter => @this.Count++;

[agocke]

@copilot this should read: the receiver is an anonymous type parameter constrained to the containing interface. It’s also a by-ref parameter

[Copilot]

Done in 5dfd6d8 - updated the wording throughout to clarify that the receiver is an anonymous type parameter constrained to the containing interface, passed by reference.

[agocke]

@copilot Please add as a primary drawback:

The type of this is not resolved by dynamic dispatch. Meaning that further explicit interface implementations will still have this as type TSelf where TSelf : <parent interface> rather than the concrete type.

[jjonescz]

Can we somehow control whether the "receiver type parameter" has allows ref struct constraint?

[jjonescz]

nit: this bullet point seems superfluous given there is a whole section for lowering below

[jjonescz]

It looks like this bullet point is basically duplicated from above.

[jjonescz]

Can we have an example of lowering an override too?

[jjonescz]

What about instance operators?

[jjonescz]

Oh, okay, so it's not possible to override the default implementation using normal methods like for non-this default interface members? Is there a reason for that (presumably the compiler could lower such override to this static form)?

[jjonescz]

I assume this is disabled on interface members without bodies. Should we clarify that?

[jjonescz]

It's not possible to "override" the default implementation with this though right?

[jjonescz]

We could allow readonly this default interface members I guess.