On 7/23/14, 3:39 PM, H. S. Teoh via Digitalmars-d wrote:
On Wed, Jul 23, 2014 at 02:35:03PM -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
On 7/23/14, 11:52 AM, H. S. Teoh via Digitalmars-d wrote:
[...]
I fully agree that we should not autogenerate opCmp if the user
defines opEquals, since not all types comparable with equality are
orderable. However, surely all orderable types are
equality-comparable!
http://en.wikipedia.org/wiki/Lattice_(order)
[...]
And why should this be the default behaviour? The <, <=, >=, > operators
imply linear ordering, not general partial order. If you really want to
implement a non-linear partial ordering, you can always define both
opCmp and opEquals. This should be the *non*-default case, since in the
vast majority of cases, defining opCmp means you want a linear ordering.
Linear ordering should be default, and partial ordering possible if the
programmer explicitly asks for it (by implementing opEquals manually).
I'm unconvinced. Most algorithms that need inequality don't need
equality comparison; instead, they consider objects for which both !(a <
b) && !(b < a) in the same "equivalence class" that doesn't assume they
are actually equal.
Bottom line, inferring opEquals from opCmp seems fishy.
Andrei
