On Saturday, 26 July 2014 at 09:48:55 UTC, Andrei Alexandrescu
wrote:
On 7/26/14, 2:19 AM, "Marc Schütz" <schue...@gmx.net>" wrote:
On Saturday, 26 July 2014 at 07:42:05 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 26 July 2014 at 06:50:11 UTC, Manu via
Digitalmars-d wrote:
It's okay, I hate it too.
But I equally can't abide == meaning something different
than <, <=,
etc.
That's insane.
Yes, it is unsound to use opCmp for types that aren't totally
ordered:
Yes, that's why it's possible to provide opEquals in addition
to opCmp.
But for the vast majority of cases, opEquals _is_ equivalent
to opCmp ==
0, and element-wise equality is not. Defining opEquals to be
the latter
by default _even in the presence of opCmp_ is therefore wrong
in almost
all cases.
Case-insensitive ordering is a simple example. Field for field
comparison is the right default whether or not opCmp is defined.
If you're starting with the premise that the user's intention was
to keep the default semantics of opEquals, then yes. I just find
this unlikely. To take your example, I for one would fully expect
"hello WORLD" and "Hello World" to be considered equal in all
circumstances, not just when sorting.
If you want it to be restricted to sorting, it should probably
not be a property of the type, but a predicate should be used
instead for sorting. If you still want it to be different, just
define an opEquals, it's trivial using `tupleof`.
Indeed, both options make assumptions about the user's
intentions, but IMO the assumption for opEquals not using opCmp
is the more unlikely one. Maybe we can then at least require the
user to specify explicitly what she wants, as H.S. Teoh (?)
suggested? Maybe for now implement whatever has been the default
before to minimize breakage, but deprecate it with an appropriate
message, and remove it a few releases down the road?
