Proposal: Extension Methods

[janderson]

Nick Sabalausky wrote:
> 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".
> 
> 

Walter talked about the proposal for interchangeable method/functions. 
It was talked about at the D conference.  I'm not sure how much 
resistance he got to the idea.

I'm a big fan on interchangeable function/methods without the additional 
syntax as it would push the flexibility to the user rather then the lib 
designer.  I have mentioned it several times.

-Joel