On Wed, 04 Nov 2009 09:47:28 -0500, Andrei Alexandrescu <[email protected]> wrote:

I wanted to discuss operator overloading a little bit. A good starting point is Don's proposal

http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP7

which discusses the issues involved and makes one major proposal - that of equivalence of operators that gives the compiler freedom to eliminate temporaries.

Another trend is moving from many named operators to few templated operators that simply pass the name of the operator as a compile-time string. (If there's a need for virtual functions, it's trivial to have the template dispatch to several virtual functions.)

There's a third, more recent idea. When we were discussing about array-wise operations, Walter mentioned that he sees no reason why

a[] = b[] + x * c[] * d[];

should not work on other types than built-in arrays. I think that's a great idea.

For built-in arrays, that does today

assert(a.length == b.length);
assert(a.length == c.length);
assert(a.length == d.length);
foreach (__i; a.length) a[__i] = b[__i] + x * c[__i] * d[__i];

The general technique is called loop fusion or at least is related to it. Instead of writing several loops that compute parts of the expression, the statement only defines a loop that does all operations.

So, Walter's idea is to extend such expressions to general ranges. If the right-hand side of an expression involves ranges and scalars, and if the left-hand side is a range, then the compiler simply writes the loop around the lockstep iteration.

I'm unclear how detection would work, e.g. what if a range wants to define "+" itself to do something else than fusion? Should operator overloading be banned for ranges? That would be too restrictive because sometimes you actually don't want fusion.

If we define this well, we can say that the operator overloading is quite complete, without growing the language. Between fusion, ETs, and temporary elimination, I think we got most everything covered.


Andrei

I like this idea. Intuitively the syntax should also work with ranges of ranges (or arrays of arrays) efficiently.

Reply via email to