Bug 5558 – opIn_r not detected as method for 'in' in pointed struct
Status
RESOLVED
Resolution
FIXED
Severity
normal
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
x86
OS
All
Creation time
2011-02-10T09:47:43Z
Last change time
2020-03-21T03:56:39Z
Keywords
spec
Assigned to
No Owner
Creator
Denis Derman
Comments
Comment #0 by denis.spir — 2011-02-10T09:47:43Z
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
Comment #1 by smjg — 2011-02-10T10:51:30Z
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?
Comment #2 by schveiguy — 2011-02-10T11:10:45Z
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...
Comment #3 by denis.spir — 2011-02-10T13:28:26Z
(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