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?
