www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 5558] New: opIn_r not detected as method for 'in' in pointed struct

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5558

           Summary: opIn_r not detected as method for 'in' in pointed
                    struct
           Product: D
           Version: D2
          Platform: x86
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: denis.spir gmail.com



---
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

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 10 2011
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5558


Stewart Gordon <smjg iname.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |spec
                 CC|                            |smjg iname.com
         OS/Version|Linux                       |All



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?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 10 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5558


Steven Schveighoffer <schveiguy yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schveiguy yahoo.com



11:10:45 PST ---
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...

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 10 2011
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5558




---


 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

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 10 2011