opEquals/opCmp returning other types

Simen Kjærås simen.kjaras at gmail.com
Sun Mar 18 18:15:11 PDT 2012


On Mon, 19 Mar 2012 01:54:27 +0100, Brian Palmer <brian+d at codekitchen.net>  
wrote:

> I'm working on a DSL for generating SQL queries, based loosely on  
> Python's SQLAlchemy and Ruby's Sequel. One nice thing about the DSL is  
> the compact syntax for specifying WHERE clauses. With some fiddling, I  
> got it working for opEquals, a simplified example:
>
>    foreach(network; db["networks"].each) {
>      writefln("network: %s", network.name);
>      foreach(host; db["hosts"].where(db.c.id == network.id)) {
>        writefln("\thost: %s", host.address);
>      }
>    }
>
> This works because db.c.id returns a struct which defines an opEquals  
> which returns a "Filter" struct, rather than an int. I'm not positive  
> that it should really be allowed by the compiler, but it works:
>
> struct Filter { ... }
> struct Column {
>      Filter opEquals(T)(T rhs) { ... }
> }
>
> Then the .where call takes a filter, and uses it to output a snippet of  
> sql like "id = 5"
>
> However, this won't work for comparison operators like < and >, which  
> all map to opCmp, or for != (since that's rewritten to !(a == b))
>
> I guess I have two questions, one, am I going to shoot myself in the  
> foot by going down this path, because it only happens to work due to the  
> compiler being too lax? And is there interest in extending D to allow  
> the rest of the operators to return non-boolean results? I'm thinking  
> something like falling back to opBinary!("<"), etc, if opCmp isn't  
> defined for a struct.

I for one, agree that having opEquals and opCmp return irregular types
is awesome.

Now, I see there are very good reasons to leave the behavior of all
those 'derived' operators to the compiler. Except, of course, when you
want to do something weird, like you're doing now. I also think that
the 'D creed' states that 'the simple should be easy, the complex
possible'.

I like the idea of opBinary!"<", but would perhaps argue for
opBinaryComparison!"<", to distinguish it from the 'normal' operators.


More information about the Digitalmars-d mailing list