Operator overloading or alternatives to expression templates

[Andrei Alexandrescu via Digitalmars-d]

On 09/13/2015 10:06 AM, Martin Nowak wrote:
> On 09/13/2015 05:03 AM, 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 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.
>
> But this is not an argument to rule out `opBinary!"<"`.

Agreed.

> To summarize the arguments.
>
> - logical indexing x[x < 20]
>
>    e.g. opBinary!"<" returns a bit mask to select entries of a large vector

Good one. But niche, can be solved with a function, etc.

> - faster comparison
>
>    struct Foo
>    {
>        size_t id;
>        int opCmp(Foo rhs)
>        {
>            if (id < rhs.id) return -1;
>            if (id == rhs.id) return 0;
>            else return 1;
>        }
>        bool opBinary(string s:"<")(Foo rhs)
>        {
>            return id < rhs.id;
>        }
>    }
>
>    Sorting a million Foos w/ random ids is 37.5% slower with opCmp.
>
>    foos.sort!((a, b) => a.opBinary!"<"(b))(); // 104ms
>    foos.sort!((a, b) => a < b)(); // 143ms

I think this is a good candidate for a peephole optimization.

> - expression templates
>
>    I'm well aware of the limitations, but still think it will work out
> nicely for an ORM b/c there is precedence in other language, e.g. Rails'
> (ActiveRecord) query syntax.

Fine, but let's not forget the ET experience in D will be a lot closer 
to that in C++ than that in Rails. And that doesn't bode well.

> - language regularization
>
>    It's surprising to find these "arbitrary" language limitations.
>    The non-predictability of what's possible has always been a huge issue
> for me with C++, i.e. you come up with an idea, spend 4 hours
> implementing it only to find out that the small detail x isn't feasible.

This is the case in all powerful languages. Martin Odersky told me 
there's a constant problem with Scala having such a powerful type 
systems, the envelope of what can and cannot be done with it is really 
fuzzy and frustrates its power users.


Andrei