Proposal: Extension Methods

[Chris Wright]

Nick Sabalausky wrote:
> "Chris Wright" <dhasenan at gmail.com> wrote in message 
> news:g0pcpm$14f2$1 at digitalmars.com...
>> Or: auto a = "file.txt".readText.split.map!(to!(int)));
>>
>> Now, since "file.txt" is an array, readText returns an array, and split 
>> returns an array, you can currently do this. Were any of those a class, 
>> struct, or scalar, you'd be SOL until uniform call syntax is implemented.
>>
> 
> Heh, true, I wasn't thinking about that example using all arrays. Bad 
> example :)
> 
> Does eliminating the no-argument parentheses like that currently work, or 
> are you proposing that?

It works currently. In dunit assertions, for instance, you can do:
expect(foo).not.sameAs(bar);
// equivalent to expect(foo).not().sameAs(bar);

>> I wonder if uniform call syntax could be used the opposite way:
>> class A
>> {
>> void foo(){}
>> }
>> foo(new A);
> 
> That's been my assumption. After all, isn't that what happens 
> behind-the-scenes anyway (ie, "this" being passed as a hidden first 
> parameter)? (I know it is in C++)
> 
> But, I wonder if disallowing that might eliminate some of the concerns I had 
> about "uniform call syntax"/"implicit extension methods". I'll have to think 
> about that.

I'm not sure how you would explicitly use the class method rather than 
the free function if it were allowed. I just thought it was amusing.