Operator overloading or alternatives to expression templates

[deadalnix via Digitalmars-d]

On Sunday, 13 September 2015 at 03:03:44 UTC, Andrei Alexandrescu 
wrote:
> On 09/12/2015 04:08 PM, Martin Nowak wrote:
>> On Friday, 11 September 2015 at 23:47:42 UTC, Andrei 
>> Alexandrescu wrote:
>>> 1. Use lambdas, which seem to already do what you want:
>>>
>>> db.get!Person.filter!(p => p.age > 21 && p.name == "Peter")
>>>
>>> The way this'd go, the db.get!Person() call returns an input 
>>> range of
>>> Person. Presumably introspection is being used to bind fields 
>>> in the
>>> query such as "age" and "name" to static field names in 
>>> struct Person.
>>> Then good old std.algorithm.filter takes care of the rest.
>>
>> I'm instantiating the lambda with a fake p to capture the 
>> expression so
>> I can translate it to whatever SQL, MongoDB, columnar db is 
>> used.
>
> 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 
> 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.
>

Once gain, that says more about C++ than anything else. C# have 
such mechnism and users seems very happy with it.

>>> 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.
>

That sounds like a bigger problem than whatever you mentioned 
before.