On Wednesday, 23 July 2014 at 23:52:01 UTC, Andrei Alexandrescu
wrote:
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
NaN is a good example.
