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.
