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