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

[Jonathan M Davis via Digitalmars-d]

On Fri, 16 May 2014 16:45:28 +0000
Yota via Digitalmars-d <digitalmars-d at puremagic.com> wrote:

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

That sounds like an interesting idea, but it would require adding the concept
to the compiler - though I suppose that that's a downside with monarch_dodra's
original proposal as well. Neither can be done in the library itself. That's
not necessarily the end of the world, but at this point, I'm very hesitant to
support adding another attribute to the language without a really, really good
reason.

This particular problem can be solved by Steven's suggestion of using proxy
functions with different names, which works within the language as it's
currently defined. So, while that might not be an altogether desirable
solution, I'm inclined to believe that it's good enough to make it not worth
adding additional attributes to the language to solve the problem.

- Jonathan M Davis