Uniform Function Call Syntax in D - GameDev.net

[dennis luehring]

Am 02.07.2012 07:13, schrieb 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
>

but the compiler selects the member-functions silently - thats odd, ok i 
will see it very fast - but then i need to change my code anyway - so 
whats the reason for the silent "overwrite"?