opEquals/opCmp returning other types

[Brian Palmer]

On Monday, 19 March 2012 at 15:33:33 UTC, Andrei Alexandrescu
wrote:

> For D, hooking built-in operators is a poor way to implement 
> DSLs. Best is to use strings, CTFE, and mixin.
>
>
> Andrei

Hmm I have to say I'm not (yet) convinced. But I'll try to drink
the kool-aid and see if it converts me. I'd love some help, as
I'm still no D expert. My initial gut reaction, since I already
plan to support arbitrary SQL snippets in where clauses, is to
modify the where() method to something like:


    foreach(network; db["networks"].each) {
      writefln("network: %s", network.name);
      foreach(host; db["hosts"].where("hosts.id = ?", network.id)) 
{
        writefln("\thost: %s", host.address);
      }
    }

Which, in a lot of ways, it's very cool that I can
parse that at compile time. However, I see a few problems
already. First of all, where can a reasonable line be drawn
between arbitrary SQL, and snippets where we parse and actually
understand the snippet?

On one extreme, I could implement a full SQL parser and parse any
given snippet to pull out identifiers and such. Sounds painful,
but potentially awesome.

The other extreme is to just treat *all* where clauses as SQL
snippets with no extra "smarts", but if I do that, suddenly I've
lost a whole lot of functionality and my library is less useful
(it can't auto-quote identifiers, intelligently combine
conditionals and add aliases or scopes to identifiers, a whole
slew of useful functionality is gone).

A middle ground would be to just parse a simple subset of
possible snippets, and treat any we don't understand as raw SQL.
But that seems like a surprising, frustrating experience for
users of the library.

Anyway, I'm going to play around with the idea, see if I can
convince myself. Any advice on how to convince myself would be 
appreciated. :)