On Tuesday, March 19, 2013 21:13:21 timotheecour wrote: > > That's opEquals' job. It deals with recursive comparisons like > > you're describing here just fine. > > Except the functionality is very different, as opEquals is blind > to range semantics.
opEquals defines equality however it chooses to define equality. It's trivial for it to use equal on any member variables which are ranges. opEquals is the way that the language defines equality. equal is only necessary when trying to compare the elements of two ranges rather than compare two objects. == is what is supposed to be used to compare two objects. You seem to basically be trying to work your way around the language rather than using it the way it's designed, which is just asking for trouble. And if the problem is that you don't want to write boilerplate code, and you want to define an opEquals that compares ranges with equal and everything else with ==, then it would be fairly trivial to write a string or template mixin to mix in opEquals for you. If you avoid defining == properly, then you're going to have problems wiith all kinds of stuff which assumes that == is used to define equality (including stuff like the built-in AAs). Avoiding boilerplate code is poor excuse to give your types odd semantics by not defining opEquals and using an external function to compare for equality. - Jonathan M Davis
