Uniform Function Call Syntax in D - GameDev.net

[Timon Gehr]

On 07/03/2012 09:55 PM, bearophile wrote:
> Jonathan M Davis:
>
>> Yes, but as I said, if it _didn't_ select the member function when
>> there was a
>> conflict, it would be impossible to call the member function whenever
>> there was
>> a conflict. There is no way to indicate that you mean a member
>> function rather
>> than a free function. The normal way to do that is to use member
>> function call
>> syntax, and UFCS allows you to then use that for free functions. With
>> conflicts
>> between free functions, you can do path.to.func or other.place.func
>> instead of
>> just func, but with a member function, that's not possible. So,
>> without adding
>> new syntax to the language,
>
> I understand. This is Nick Sabalausky example:
>
>> import std.stdio;
>>
>> void bar(Foo f) {
>>     writeln("UFCS");
>> }
>>
>> struct Foo {
>>     void bar() {
>>         writeln("Member");
>>     }
>> }
>>
>> void main()
>> {
>>     Foo f;
>>     f.bar();
>> }
>
>
> So let's assume the language gives an compile error here, because there
> is a conflict.

There is no conflict. The method takes precedence.

> If you want to call the free function you use bar(f). If
> you want to call the bar method of Foo, you can't, because it's
> ambiguous, and as you say there is no alternative (simple) syntax to
> specify you want the method of Foo.
>
> This is a limitation. But is this a problem?

Certainly.

> If you want to call Foo.bar
> then you don't import the free function bar in the current scope. How
> often do you want to keep both the free function and a method with the
> same name and you wan to call the method?
>

Every time you want the free function to be a generic implementation
that works for everything and the method to be a specialisation for the
respective type if present.

The question you should be asking is: "How often do you want to keep
both the function and a method with the same name and don't want to
call the method?" I cannot think of a single case.

> So maybe it's worth accepting this limitation, to reduce confusion for
> the people the read the code.
>

It does not do that.

It does not matter whether or not a function is a member function. Why
would it make any difference?