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

[Yota via Digitalmars-d]

On Thursday, 15 May 2014 at 17:08:58 UTC, monarch_dodra wrote:
> On Thursday, 15 May 2014 at 12:16:52 UTC, Steven Schveighoffer 
> wrote:
>> On Thu, 15 May 2014 02:05:08 -0400, monarch_dodra 
>> <monarchdodra at gmail.com> wrote:
>>
>>> "move" will also delegate to "proxyMove".
>>
>> This is the correct solution IMO. The principle of least 
>> surprise should dictate that a.foo should always mean the same 
>> thing. All that is required to enforce this is to make the 
>> "hook" function have a different name.
>
> The issue(s) I have with the "hook must have a different name" 
> is:
> 1. In the algorithm implementation, you must explicitly test 
> for the hook, which, if we want to expand on, would turn all 
> our algorithms into:
> void foo(T)(T t)
> {
>     static if (is(typeof(t.fooHook())))
>         return t.fooHook();
>     else
>         ...
> }
> 2. The "overriden" hook is only useful if you import the 
> corresponding algorithm. So for example, in my 3rd pary 
> library, if my type has "findHook", I'd *have* to import 
> std.algorithm.find for it to be useful. Unless I want to make a 
> direct call to "findHook", which would be ugly...

How about a middle ground?  Have the function names be identical, 
and decorate the member version with @proxy or @hook, rather than 
decorating the original definition.  I'd find this to be less 
surprising.