On 26 July 2014 19:48, Andrei Alexandrescu via Digitalmars-d < digitalmars-d@puremagic.com> 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. > ...you're trolling me right? Just to be clear, you're saying you think it's reasonable for <, <=, >=, > to perform case insensitive comparison for ordering purposes, but for ==, != to be case sensitive for equality comparisons? You're saying you think that's what the user *probably* wants, by default? Is there precedent for something like this? I've never seen anything like it. It creates very awkward relationships between the suite of operators which is likely to break down in many logical constructs. I don't understand; your example is the perfect example of why opCmp==0 should be the default opEquals, but somehow it's an argument against? I have no idea how to reason about this topic. I come from a place where <,<=,==,!=,>=,> are a suite, and it is reasonable to assume they all work the same. Is that not the default presumption of modern programmers? Is it really so unlikely that people would make the mistake of assuming they are related?