Uniform Function Call Syntax in D - GameDev.net

[Jonathan M Davis]

On Monday, July 02, 2012 07:00:23 dennis luehring wrote:
> Am 01.07.2012 23:02, schrieb Walter Bright:
> > On 7/1/2012 11:53 AM, Nick Sabalausky wrote:
> >> That successfully compiles and prints "Member". Same thing happens if
> >> you move the UFCS func and Foo definition out into their own separate
> >> modules. But I was expecting a conflict error at compile-time. Is this
> >> a bug?
> > 
> > No, it's correct behavior. A real member overrides.
> 
> isn't that some sort of highjacking then?

More like it avoids hijacking. It stops you from creating a function which is 
used instead of the one which is on the class or struct.

Granted, this does mean that you could be surprised about your external 
function not being called, and adding a new member function could cause your 
existing external function to no longer be called (which could be a problem), 
but realistically there's no other way to handle the situation. It's possible 
to explicitly give a path to the free function (e.g. path.to.function), but 
there's no way to do that for a member function, since there's only one way to 
call it. So, if you were forced to disambiguate, you could never indicate 
anything else other than the free function - not without introducing a new 
syntax to indicate the member function.

- Jonathan M Davis