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

On Wed, 04 Nov 2009 09:47:28 -0500, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> 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.

Andrei Alexandrescu 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
> 

Just read it and I hate it.

Nobody is smart enough to think of all the possible uses for operator overloading and make a decision as to whether they are valid or worth while.

D's fucktarded ('scuse me, but it really sucks) operator overloading is the *one* and only respect where C++ still rules D.

Just because you (for certain values of you) deal with numbers doesn't make the relationship between <, > >= etc cast in stone and semi quoting an early paper by 'Bjarne Stroustrup' doesn't give any credence to the argument; he was wrong then and so is Don now.

(and btw, does Bjarne still feel operator abuse is a bad idea?)

boost::spirit and boost::Xpressive are 2 for instances, which make incredibly good use of operator abuse to achieve seriously useful functionality.

I think the main problem is calling these functions 'operators'.

Rather step back and call them 'infix function notation'.
Stop imagining the objects they operate on as numbers and then you can
do some really funky things.

D needs more operators not less and operators defined globally; so I can finish porting boost::spirit properly.

- --
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk

div0 wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Andrei Alexandrescu 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
>>
> 
> Just read it and I hate it.
> 
> Nobody is smart enough to think of all the possible uses for operator
> overloading and make a decision as to whether they are valid or worth while.
> 
> D's fucktarded ('scuse me, but it really sucks) operator overloading is
> the *one* and only respect where C++ still rules D.
> 
> Just because you (for certain values of you) deal with numbers doesn't
> make the relationship between <, > >= etc cast in stone and semi quoting
> an early paper by 'Bjarne Stroustrup' doesn't give any credence to the
> argument; he was wrong then and so is Don now.
> 
> (and btw, does Bjarne still feel operator abuse is a bad idea?)
> 
> boost::spirit and boost::Xpressive are 2 for instances, which make
> incredibly good use of operator abuse to achieve seriously useful
> functionality.
> 
> I think the main problem is calling these functions 'operators'.
> 
> Rather step back and call them 'infix function notation'.
> Stop imagining the objects they operate on as numbers and then you can
> do some really funky things.
> 
> D needs more operators not less and operators defined globally;
> so I can finish porting boost::spirit properly.
> 
> - --
> My enormous talent is exceeded only by my outrageous laziness.
> http://www.ssTk.co.uk
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iD8DBQFK82sMT9LetA9XoXwRAjXxAJ40jHoQqal1l6/vpV3lNlEJwT+AKgCgtOWG
> QWQpTFfEH80eqxm5TpvU0xU=
> =/62J
> -----END PGP SIGNATURE-----

One of D's strongest points is it's discouragement of 'funky things'. Operators like compare are designed for things like sorting, and doing funky things with them (for example, modifying the internal state of an object) should be something that is discouraged.

Keep operators logical, and use other language features such as delegates if you want to do 'funky things'.