Proposal: Extension Methods

[Bruno Medeiros]

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:
> 

Overall it seems like an interesting idea. Note: I would prefer the syntax:
   void Foo(MyClass this, int a, ...) {...

Some other details might need to be worked out, but overall it looks sound.

> - 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.
> 

For the sake of consistency, I think it would be best if rule #2 remains.

> - 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".
> 
> 

I would prefer not. In fact, I think it would be useful that even class 
methods would be callable with an explicit 'this' parameter, like this:

   class Foo {
     void func(int a);
   }

   auto foo = new Foo();
   Foo.func(foo, 2); // same as foo.func(2);

The benefit of this, is to be able to use Foo.func as a function 
pointer, and thus we would have a feature similar to C++'s member 
functions, as well as the ability to call a specific override in a 
method override lineage.


-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D