Bug 5155 – [AA] AssociativeArray.get does not compile when opBinary("in") is defined.

If an appropriate "in" opBinary function is defined, AA.get calls that instead of the actual built-in "in" operator. As I can see no reason, type wise, for this to be so, this may be rooted in a DMD error. Also, complex templates can cause an ICE: I found this bug after tracing down an instance of Issue 5079 (glue.c, 1103) due to a std.variant unit test instantiating This[This]. Using DMD 2.050: In Object.di: Line 366: - void* _aaIn(void* p, TypeInfo keyti); + void* _aaIn(void* p, TypeInfo keyti,...); Lines 413: - auto p = key in *cast(Value[Key]*)(&p); + auto ptr = cast(Value*) _aaIn(p,typeid(Key),key); In Object_.d: Line 2218: - void* _aaIn(void* p, TypeInfo keyti); + void* _aaIn(void* p, TypeInfo keyti,...); Line 2296: - auto p = key in *cast(Value[Key]*)(&p); + auto ptr = cast(Value*) _aaIn(p,typeid(Key),key); Test case (doesn't ICE): struct Bug { int x; Bug opBinary(string op, T)(T rhs) { return Bug; } } void main(string[] args) { Bug key1 = Bug(1); Bug key2 = Bug(2); Bug value1 = Bug(3); Bug value2 = Bug(4); Bug[Bug] bug = [key1:value1]; assert( bug.get(key1,value2).x == value1.x); assert( bug.get(key2,value2).x == value2.x); int[string] vals; vals["x"] = 1; assert( vals.get("x", 0) == 1 ); assert( vals.get("y", 0) == 0 ); }

(In reply to Rob Jacques from comment #0) > As I can see no reason, type wise, for this to be so, this may be rooted > in a DMD error. How so? The implementation of get() clearly contains: auto p = key in aa; Here, the compiler correctly tries invoking opBinary!("in") on the left-hand operand first, followed by opBinaryRight on the right-hand one. I don't understand why you consider this to be a DMD error. The compiler is correctly following the spec. > Also, complex > templates can cause an ICE: I found this bug after tracing down an instance > of Issue 5079 (glue.c, 1103) due to a std.variant unit test instantiating > This[This]. That would need to be filed separately. > Lines 413: > - auto p = key in *cast(Value[Key]*)(&p); > + auto ptr = cast(Value*) _aaIn(p,typeid(Key),key); This looks like it might be a small optimization, however it mainly looks like a workaround for broken user code. Associative arrays are planned to be converted to an entirely templated implementation, so this patch will soon no longer be applicable either way. Closing, per the arguments above, and as this issue is over 6 years old.