Proposal: Extension Methods

[Nick Sabalausky]

I thought I had seen discussion on something like this back when the 
"Functions as Array Properties" feature was introduced, but I just did a 
search and didn't see much of anything. So sorry if this has been discussed 
to death before.

I propose adding to D a feature that C# calls extension methods. These are 
similar to D's "Functions as Array Properties", but provide more control and 
flexibility.

For any function that's not a member of a class (and maybe also static 
member functions of classes), if you add the modifier "extend" or "this" to 
first argument of the function declaration like this:

// Normal Function
void Foo(MyClass arg) {/*...*/}

// Extension Method (I'm proposing either of these, but not both):
void Foo(this MyClass arg) {/*...*/} // C#-style
void Foo(extend MyClass arg) {/*...*/} // Might be more readable

(Although, there wouldn't actually be overloading based soley on whether or 
not it's declared as an extension method. (Or would there? Probably not.))

Then that allows you to call Foo like this:

auto obj = new MyClass();

// Always allowed
Foo(obj);

// Allowed if and only if Foo has been declared
// using the above extension method syntax.
// But regardless, Foo never has access to private members
// of MyClass, since it still isn't a true member.
obj.Foo();

This should also be allowed for primitives:

void Foo(extend int arg);
int myInt = 7;
myInt.Foo();
5.Foo(); // Might interfere with parsing of floating-point literals, though.

This has two advantages over the current "Functions as Array Properties" 
feature:

1. It supports more than just arrays (obviously).
2. The special syntax is only available if the function's author intends it 
as a non-member "extension" to the given type.

Possible modifications to this proposal:

- If advantage #2 is deemed to be an unwarranted concern, I'd be happy to at 
least have the current "Functions as Array Properties" feature extended to 
all types, not just arrays.

- Maybe declaring a function as an extension method would *require* it to be 
called using extension method syntax. Although under this arrangement, if 
you wanted a function to be callable via either syntax (but would this 
ability really be desirable?), that would require a function overload or a 
messy kludge like using "maybe_extend" instead of "extend".