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? I know
that some of the UFCS code was written without regard to hijacking.
(There is a comment in the code noting that it will not compile.)
Right, but I wasn't sure what errors you expected to see. I hate to assume with
these sorts of things, as people often post examples with errors they didn't
intend. This is why I ask for examples, and it's nice to also point out the errors.
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 :-)
ADL in C++ makes lookups bafflingly complex, and I doubt many C++ people
actually understand it. It's like C++ overload resolution, nobody understands
it, not even me (and I implemented it to the letter of the spec!). Some will
argue it "just works", and no understanding is necessary, and I suppose that's
fine until one gets an incomprehensible compiler error.
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.
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.)
---
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.stdio;
for(auto r=iota(0,10);!r.empty;r.popFront){ // ok
writeln(r.front);
}
import std.algorithm;
iota(0,10).each!writeln; // error
foreach(i;iota(0,10)) writeln(i); // error
}
---
If I copy-paste portions of std.range into the main module of the above program
instead of importing, I will be able to use my custom type with those Phobos
ranges.
I understand this one, as it helpfully says the expected error :-) thank you.
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. Doing this kind of
wrapper doesn't work for operator overloading, which brings us back to ADL is
for operator overloading.
