On Monday, 2 July 2012 at 05:55:20 UTC, dennis luehring wrote:
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"?
If it didn't overwrite silently, it would mean every single free
function is now not a valid member function name. Better hope
your users don't import a module that uses said free function.
In my opinion, the current way is the one that makes sense. And
extension methods in C# do this as well.
