In a struct, opIn_r is not detected by the compiler as beeing the method implementing the operator 'in'. Example: struct S { int i; void show() { writeln(i); } const bool opEquals (ref const(S) s) { writeln("=="); return (i == s.i); } bool opIn_r (int j) { return (i==j); } } unittest { S* sp = &(S(1)); writeln(sp.i); sp.show(); S s2 = S(1); writeln(sp == s2); writeln(1 in s2); // error: writeln(1 in sp); } ==> Error: rvalue of in expression must be an associative array, not S* This concerns opIn_r on pointed struct only; the other struct members of the structn and the not-pointed one are only here to contrast: * Data members, regular methods and even "language methods" like opEquals are correctly taken into account on a struct, even via implicite deref. * opIn_r is correctly detected as implementing 'in' on a non-pointed or explicitely dereferenced struct. Thus, the code works fine if one comments out the very last line. Waiting for a fix, the error message should be corrected to eg: Error: right operand of 'in' operation must be an associative array or implement the operator 'in' via method opIn_r Denis
This is part of a more general issue: implicit dereference works only on the left operand. I'm not sure whether it's meant to work. What does the spec say on the matter?
Actually, I feel that it should work on both sides. The spec states that the compiler rewrites for example "a + b" as: try a.opBinary!("+")(b), see if it compiles, if not, try b.opBinaryRight!("+")(a). Since the dot operator automatically dereferences, I think it should also in this case after the rewrite. Note, opIn_r is not supposed to be used anymore, opBinaryRight!("in") is used, but it still should be a rewrite. However, the opBinaryRight!("in") doesn't work at all...
(In reply to comment #2) > Actually, I feel that it should work on both sides. The spec states that the > compiler rewrites for example "a + b" as: > > try a.opBinary!("+")(b), see if it compiles, if not, try > b.opBinaryRight!("+")(a). > > Since the dot operator automatically dereferences, I think it should also in > this case after the rewrite. And unlike opBinary, opIn_r so-to-say says "as right operand", so the compiler has no excuse ;-) (And does not need to try both possibilities.) Denis