https://d.puremagic.com/issues/show_bug.cgi?id=11161
timon.g...@gmx.ch changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |timon.g...@gmx.ch --- Comment #7 from timon.g...@gmx.ch 2013-11-09 06:49:13 PST --- (In reply to comment #6) > (In reply to comment #2) > > 1. Find opEquals method from the type of operands > > 2. If 'alias this' declaration exists, compiler tries to resolve equality > > operation via alias this. -> `t1.value != t2.value` is tested, and succeeds > > to > > compile. > > Just to be clear, currently we have this: > --- > struct S > { > int i, j; > alias j this; > } > > void main() > { > S s1 = {0}, s2 = {1}; > assert(s1 == s2); // ok, resolved as `s1.j == s2.j` > } > --- Yah, broken behaviour. > And I'm quite sure it must be clearly documented. > > Also it should be mentioned one have to add: > --- > bool opEquals(in typeof(this) other) > { return this.tupleof == other.tupleof; } > --- > if "old" comparison behavior is needed. DMD bugs should never be carried over to the language documentation. I guess the most elegant way to fix this specific issue would be to just have all types that support a certain overloadable operator actually expose the necessary member function. E.g. 2.opBinary!"+"(3) should be legal and be treated like 2+3, where opBinary is a member of 'int'. (This would also solve the annoyance that generic code cannot rely on opCmp being present for all comparable types, though UFCS and some reflection would be sufficent to workaround this.) -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------