"hijackable"/"customizable" keyword for solving the "customized algorithm" issue?

[monarch_dodra via Digitalmars-d]

A little while ago, Steven Schveighoffer started a thread called 
"D UFCS anti-pattern". The conversation started in regards to 
"how can a generic algorithm be replaced by a custom type". In 
particular (in my original use case) "retro"

The issue just came up again in ".learn" for ".find". It comes up 
regularly with ".put".

To put it simply, the problem is "given the function std.foo, how 
can I implement myObject.foo, and make sure that that is called 
when we call foo?"

There were two options:
1. Make std.foo test "hasMember!(T, "foo")". This would hardly 
scale though, as applying it to *every* algorithm is not 
acceptable
2. For *all* calls to be UFCS style, and ignore the "anti-pattern 
issue". Even then, it means you give no guarantees as to *what* 
is called, depending on how the user writes the code. So not 
acceptable

I just had a crazy idea. "hijackable" keyword (yeah... another 
keyword):

Given a function:
"Ret foo(T input, Args... args) @hijackable"

Then, when the compiler sees:
"foo(input, args);"

It will always forward directly to T.foo if T.foo exists, 
bypassing std.foo entirely.

I think it is a clean and generic way to allow ALL algorithms in 
D much greater customize-ability.

I didn't put *much* more thought than that to it yet, so I may 
have missed something obvious? In particular, "hijack" might not 
be the correct word? "@customizable" ?

Please provide feedback/destruction ?