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.
