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

[monarch_dodra via Digitalmars-d]

On Thursday, 15 May 2014 at 02:07:40 UTC, Meta wrote:
> On Thursday, 15 May 2014 at 01:49:17 UTC, Idan Arye wrote:
>> UFCS only apply to the method call style, not the the function 
>> call style, so it's not a matter of priority here - 
>> `foo(myObject)` will not call the `foo.myObject()` method even 
>> if there is no `foo` function(in that case it'll just fail).
>>
>> Having the function call style always defer to a member 
>> function is a really bad idea - and not just because of code 
>> breakage. It'll make it impossible to call a function on an 
>> object that has a method of the same name unless you use an 
>> alias or a function variable to copy the function - but then 
>> you have to make sure the alias\variable name is also not 
>> taken!
>>
>> This will be a disaster for anyone who wants to build or use a 
>> D library that uses templates. Well, how common can that case 
>> be?
>
> That's exactly what the proposed @hijackable annotation on a 
> function would do, if I understand it correctly.

Right. The idea though is not to "customize the behavior" of the 
algorithm, but rather "provide a more efficient implementation". 
It shouldn't really break any existing code.

In any case, it should not cause any more than the breakage that 
using UFCS *already* causes... this would just (opt-in by the 
implementation) make sure you get the same behavior with/without 
UFCS.

FYI, there are already a few functions in phobos that delegate to 
member functions "if they exist", and do something generic if 
they don't. "Take" and "put" are some of the more trivial 
examples. "move" will also delegate to "proxyMove". At one point, 
there were also talks of doing the same for popFrontN too.

The issue though is that it's all very hackish, and it makes the 
implementation jump through hoops to achieve said result, and it 
only works if the implementation pre-emptivelly thought about 
doing so.