templating opEquals/opCmp (e.g. for DSL/expression templates)

Nicholas Wilson iamthewilsonator at hotmail.com
Thu Feb 14 01:07:34 UTC 2019


On Wednesday, 13 February 2019 at 18:42:43 UTC, H. S. Teoh wrote:
> On Wed, Feb 13, 2019 at 01:50:21AM +0000, Nicholas Wilson via 
> Digitalmars-d wrote:
>> On Wednesday, 13 February 2019 at 00:56:48 UTC, H. S. Teoh 
>> wrote:
>> > Frankly, I think it's a very good thing that in D comparison 
>> > operators are confined to opEquals/opCmp.
>> 
>> So do I. Many more objects have partial ordering than 
>> arithmetic, having opCmp under opBinary would be annoying.
>
> [opCmp doesn't actually work for partial ordering]

This proposal would actually let you match

<  : subset
<= : subset or equal
...

and would say, let you return a tuple of (result of predicate, 
are sets disjoint)

auto sub = setA < setB;
if (sub.pred && !sub.disjoint) { ... }

>> > Operator overloading should be reserved for objects that 
>> > behave like arithmetical entities in some way.
>> 
>> Like symbolic math.
>
> I know what you're trying to drive at, but there's a difference 
> arithmetic in code vs. arithmetic in math.

What difference? Graph execution of math math on a nice library 
looks like code math and I don't see anyone in PyTorch 
complaining.

> An expression in code is generally assumed to execute when 
> control flow reaches that line of code.

async says hello.

> It's unexpected behaviour for what looks like an assignment of 
> the result of an expression to instead assign the expression 
> itself as something to be evaluated later.

You are likely missing the context of the expression, e.g. a DB 
query, or that you are dealing with symbolic math. Or you don't 
(and can't) care because you are in generic code.

> What I meant was that == and <= should behave consistently with 
> each other.  Ideally both <= and == should be handled by the 
> same function. Then consistency would be guaranteed. But for 
> practical reasons we separate them, one reason being that often 
> equality is much cheaper to compute than linear ordering.

Also manyfold more objects can be compared for (in)equality than 
can be for ordering.


More information about the Digitalmars-d mailing list