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

[monarch_dodra via Digitalmars-d]

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...

An example for "2" are range primitives:

> I think the two mechanisms of overriding default behavior:
>
> 1. Use a hook, to define the basic minimum functionality.
> 2. Implement the same-named method, but you must implement ALL 
> functionality (possibly deferring to the global function if 
> necessary).
>
> -Steve

Also: "moveFront"/"moveBack" are other examples of such "globally 
hijack-able" functions.