Proposal: Syntax/semantics for non-static extension methods

[Lehonti]

Consider a scenario like this (a data model + an object that decides how it will be represented by the GUI):

public interface IViewPropertyResolver<TItem>
{
    Color ResolveColor (this TItem item);
}

public class PlotItemViewPropertyResolver :
    IViewPropertyResolver<PlotItem>
{
    public Color ResolveColor (this PlotItem plotItem) {
        return plotItem.Critical ? Colors.Red : Colors.Green;
    }
}

It would probably be useful to use the resolver like plotItem.ResolveColor() instead of resolver.ResolveColor(plotItem). To that end, we could have a keyword which we would use to say "in this scope, we will be able to use the methods in this instance as extensions". Note the keyword 'extensions' in the code below

void DrawItems (
    IEnumerable<PlotItem> items,
    extensions IViewPropertyResolver<PlotItem> resolver
) {
    foreach (var item in items) {
        var color = item.ResolveColor();
        // Perform operations with variable 'color'
    }
}

This would also allow us to write a 'fluent interface' for objects that don't have one, and in a more flexible way than currently allowed by static extension methods. Take the above example one step further, by allowing the keyword to be applied to readonly class fields, and imagine writing something like item. ResolveColor().GenerateLinearGradient().ToBrush()

In your opinion, what are the pros and cons of this?

[HaloFour]

I personally prefer resolver.ResolveColor(plotItem), it's much clearer where the responsibility lies.