On 05.10.2017 11:52, Walter Bright wrote:
On 10/5/2017 2:13 AM, Timon Gehr wrote:
It's easy to explain why: In C++, operators are the _only_ functions
that have UFCS.
This is in stark contrast to D, where all functions _but_ operators
have UFCS.
The proposal was allow UFCS also for overloaded operators.
Hence, this discussion is about UFCS. These are not really operator
overloading issues.
Ok, but I'm not sure what the proposal was.
UFCS allows hijacking. For an example, see:
https://github.com/tgehr/d-compiler/pull/1#discussion-diff-89697186L85
That may be a bug in the compiler. Can you produce a small test case?
struct S{
// string foo(){ return "hijacked!"; } // uncomment to hijack
}
string foo(S s){ return "not hijacked!"; }
void main(){
S s;
import std.stdio;
writeln(s.foo());
}
I know that some of the UFCS code was written without regard to hijacking.
...
I think it is by design. Lookup first tries to find members of the type,
and only if they don't exist applies UFCS lookup. Therefore, if members
are added to the type or made visible, this may hijack existing UFCS usages.
The way to fix it is to do UFCS lookup always and then error out if both
UFCS and member lookup match, but there is probably quite some code
relying on the fact that you can provide a custom implementation of a
general UFCS function by just adding a member. Also, with the hijacking
error if you actually meant the member function the only way out I see
is to use __traits(getMember, ...) for disambiguation.
(BTW: Local imports allow hijacking too. Maybe this one could be fixed?)
The intention of the code was to demonstrate that a type can pass
isInputRange in the same module in which it does not support front.
This is an example of surprising name lookup behavior.
I submit it is surprising only if you're used to ADL :-)
...
I'm not used to ADL. I think it is surprising because input ranges
support front. ;) (It's not surprising to _me_, I'm rather familiar with
D's features, especially those added before last year or so. My
statement is more that it could be surprising to many, and that it is
not necessarily reasonable to blame them for being surprised.)
...
D's name lookup rules were quite simple, and deliberately set up that
way. Unfortunately, most people thought they were unintuitive. It turns
out that simple algorithms are not intuitive, and we now have a fairly
complex lookup system. Martin and I implemented it, and probably neither
of us completely understands it. I find it regrettable that things have
gotten to that state.
...
It might make sense to sit down at some point and see what goals the
complex rules try to achieve and then come up with simpler rules that
achieve the same (or better) goals.
Of course there is also the opposite problem. You can have a type that
supports all range primitives via UFCS but does not pass isInputRange,
because Phobos does not import the module where the primitives are
defined. (This particular case is sometimes solved by ADL, sometimes
not.)
...
I suggest for this case writing a wrapper type for Iota, with
front/empty/popFront as members of that wrapper, then it should be good
to go. It's hardly any more work than writing the free functions.
One thing that currently works is having the following string constant
in a util.d file:
enum ufcs_=q{
private{
import std.typecons: Proxy;
struct UFCS(T){ T payload; mixin Proxy!payload; }
auto ufcs(T)(T arg)@trusted{ return *cast(UFCS!T*)&arg; }
}
};
Then, the following code compiles and runs:
import util: ufcs_;
mixin(ufcs_);
struct Iota{ private int a,b; }
auto iota(int a,int b){ return Iota(a,b); }
@property int front(Iota i){ return i.a; }
@property bool empty(Iota i){ return i.a>=i.b; }
void popFront(ref Iota i){ ++i.a; }
void main(){
import std.algorithm, std.stdio;
iota(0,10).ufcs.each!writeln; // ok
}
This exploits what seems to be a serious encapsulation-breaking bug in
std.typecons.Proxy in order to pick up all UFCS functions visible from
the current module, but a safe version of this could be made.
Doing
this kind of wrapper doesn't work for operator overloading, which brings
us back to ADL is for operator overloading.
Why does it not work for operator overloading?
