Let's say I have an interface with method overloads like this:

interface IFoo
{
 IList<Order> GetOrdersByDate(DateTime orderDate);

 IList<Order> GetOrdersByDateRange(DateTime fromDate, DateTime toDate);
}

It has two methods to get orders by date - one that gets orders for a single day, and another that gets them for a range of dates. Pretty straight forward.

Let's also assume that you want the logic for getting orders for a single date to be the same as getting them for a range of dates. When implementing the interface, you know that 99% of the time you're just going to call one method from the other, like this:

public IList<Order> GetOrdersByDate(DateTime orderDate)
{
 return GetOrdersByDateRange(orderDate, orderDate);
}

I think it would be handy to be able to enforce this behaviour back in the interface, in such a way that the implementing class didn't even have to implement the method if they chose not to. You could define your interface like this:

interface IFoo
{
 IList<Order> GetOrdersByDateRange(DateTime fromDate, DateTime toDate);


 IList<Order> GetOrdersByDate(DateTime orderDate)
 : GetOrdersByDateRange(orderDate, orderDate);
}

So now our interface is defining a default "chaining" behaviour for the single-parameter method. If you want to, you can implement that method in your class, but if you don't, it'll just call your implementation for the first method.

So it's sort of like being able to specify default values for parameters back at the interface definition. I think the constructor-chaining-style syntax is nice and understandable. What do you think?

Update: I just realised that you could achieve something very similar using an extension method on an interface to define one of the methods. That's so crazy it might work!