D issues are now tracked on GitHub. This Bugzilla instance remains as a read-only archive.
Issue 5558 - opIn_r not detected as method for 'in' in pointed struct
Summary: opIn_r not detected as method for 'in' in pointed struct
Status: RESOLVED FIXED
Alias: None
Product: D
Classification: Unclassified
Component: dmd (show other issues)
Version: D2
Hardware: x86 All
: P2 normal
Assignee: No Owner
URL:
Keywords: spec
Depends on:
Blocks:
 
Reported: 2011-02-10 09:47 UTC by Denis Derman
Modified: 2020-03-21 03:56 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description Denis Derman 2011-02-10 09:47:43 UTC
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 Stewart Gordon 2011-02-10 10:51:30 UTC
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 Steven Schveighoffer 2011-02-10 11:10:45 UTC
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 Denis Derman 2011-02-10 13:28:26 UTC
(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