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

[Meta via Digitalmars-d]

On Wednesday, 14 May 2014 at 18:05:44 UTC, monarch_dodra wrote:
> 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 ?

It's a good idea, but yet another function annotation is pretty 
much a no-go. How bad an idea is it to *always* defer to a member 
function if the object/struct in question has such a function 
defined? I thought that was the case already... I suppose it will 
cause untold amounts of code breakage. Very unfortunate.