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 ?
