Operator overloading or alternatives to expression templates

[Ola Fosheim Grøstad via Digitalmars-d]

On Sunday, 13 September 2015 at 03:03:44 UTC, Andrei Alexandrescu 
wrote:
> Yah, understood. Problem here is the approach is bound to run 
> into walls at every few steps. Say you fix the comparisons to 
> work. Then you have operators such as LIKE that are necessary

like(Person.Name,"peter%")

Person.Name == pattern("peter%")

> yet not representable in D. So more tricks are in order. This 
> is what I've seen with ET in C++ - an endless collection of 
> tricks to achieve modest outcomes at enormous costs.

FWIW, Guido wrote a similar query language to what Martin 
proposes for Google App Engine called NDB:

https://cloud.google.com/appengine/docs/python/ndb/queries

They already had a string query language called GQL:

https://cloud.google.com/appengine/docs/python/datastore/gqlreference

I never use GQL, because the NDB solution is superior in every 
way.

GQL is only for the REPL.

>>> 2. If you want to embed real SQL into D, use string-based 
>>> DSLs.
>>
>> Strings don't capture context, aren't typechecked, and require 
>> a complex
>> CTFE parser.
>>
>> db.get!Person.where!"age > 21 & name = ?"(name);
>
> Understood as well. I figure from the example you have binding 
> in mind, which is good. At some point you need to bite the 
> bullet and write a parser for the relational query language you 
> want there.

No. D should stop abusing strings. Strings should never contain 
references to type names. It makes it impossible to transpile D 
in the general case.

Walter is unlikely to change his mind on opCmp, because he has 
put a lot of emphasis on that restriction since D1, but I think 
he overreacted on some C++ libraries being less than user 
friendly.

The only thing you achieve is that people will create even uglier 
hacks to get what they want, like using a thread local global AST 
root pointer and build the AST as hidden side effects at runtime 
instead.