All this talk lately about how operators are overloaded gave me an idea that I thought I'd mention. Maybe it is something for a later version of D.

I think that it would be nice to have the ability to overload comparison and mathematical operators individually. Right now we have to overload sets of them (cmp for <,<=,>,>=,==; opMul for opMul_l and opMul_r, etc). This can be a problem when dealing objects that do not follow the rules that apply to normal numbers.

I understand the reason why it is this way: Walter wants to avoid C++-like bloat of the source (e.g. having to write 8 operators instead of one). However, I think this shortcut limits the power of D, so it would be nice to have another alternative.

And with the recently discussed mixins there would be one! Operators could by default be separate functions, much like in C++. The D standard library could then provide a "DefaultOps" mixin that provides implementations for these functions that forward the calls to the single combined function that we have right now.

Then you could still use cmp instead of defining the 8 operators individually - all you'd have to do is write "mixin DefaultOps" in the class definition. And if you want to define the operators yourself, just leave out the mixin and write your 8 functions!

Hauke

Hauke Duden wrote:
> I understand the reason why it is this way: Walter wants to avoid C++-like bloat of the source (e.g. having to write 8 operators instead of one). However, I think this shortcut limits the power of D, so it would be nice to have another alternative.

There are 2 decisions behind it which are documented in the manual, if i recall it correctly:

- operator overloading should only be used for numeric types. Everything else is considered misuse by Walter.
- commutativity of operators may be hardwired into the compiler, to enable better optimisations. Like a simple function, which gets a,b,c is faster as "return c+b+a" than return "a+b+c". This should be possible to optimise away someday. Even for overloaded opeators.

-eye

Ilya Minkov wrote:

>> I understand the reason why it is this way: Walter wants to avoid C++-like bloat of the source (e.g. having to write 8 operators instead of one). However, I think this shortcut limits the power of D, so it would be nice to have another alternative.
> 
> 
> There are 2 decisions behind it which are documented in the manual, if i recall it correctly:
> 
> - operator overloading should only be used for numeric types. Everything else is considered misuse by Walter.

True, but there are many different numeric types and lots of them follow different rules than normal integers. And for normal numbers you probably won't need to overload operators, because they are already implemented as simple types!

Or are you saying that the only good use of operator overloading is for a bignum package? That's the only thing I can think of where you need to wrap something with integer-like properties in objects, instead of using the simple integer types.

For example, matrices are used a lot in many graphics-intensive programs (games, 3D modelers, etc.), but they follow different rules. Unfortunately, you couldn't implement proper matrix-operators in D :(.


> - commutativity of operators may be hardwired into the compiler, to enable better optimisations. Like a simple function, which gets a,b,c is faster as "return c+b+a" than return "a+b+c". This should be possible to optimise away someday. Even for overloaded opeators.

I think such cases would be pretty rare, as in most cases it will be difficult for the compiler to decide which version is faster.

And in any case, I would MUCH prefer a less restrictive language than saving a few clock cycles. Let's face it, speed isn't everything nowadays and D is a high level language. There are lots of things in HLLs that technically "waste" clock cycles, but we accept them because they make our lives as programmers easier. And IMHO a potential(!) optimization possibility for some rare cases just isn't much of a justification for imposing such strict rules. There is even a good possibility that no D compiler will ever implement this optimization because there is so little to gain by it.

Hauke

Hauke Duden wrote:
> Or are you saying that the only good use of operator overloading is for a bignum package? That's the only thing I can think of where you need to wrap something with integer-like properties in objects, instead of using the simple integer types.

You could do a bignum, a fixpoint, and something like a software-steered high-precision floating point. You can also do anything which is a ring. There is an infinite number of rings you know. For example, the polynom ring. And the modulo prime rings.

> For example, matrices are used a lot in many graphics-intensive programs (games, 3D modelers, etc.), but they follow different rules. Unfortunately, you couldn't implement proper matrix-operators in D :(.

True. But the a.dot(b) notation is not that bad. Here were already proposed named and registerable operators like a "dot" b or a dot b or even something like that with unicode or other symbols, all of these having the same precedence among each other and roughly the same precedence as a function call. I even proposed that it be an error to rely on precedence in such cases, like lint can flag it on C with rarely used operators. Walter promised a syntax extension mechanism by D 2.0, and this would give us not only such, but at will also many other gimmicks.

>> - commutativity of operators may be hardwired into the compiler, to enable better optimisations. Like a simple function, which gets a,b,c is faster as "return c+b+a" than return "a+b+c". This should be possible to optimise away someday. Even for overloaded opeators.
> 
> 
> I think such cases would be pretty rare, as in most cases it will be difficult for the compiler to decide which version is faster.

There are approximate clocking tables. This way having 2 code paths, even a fairly simple compiler could decide for a shorter one. The problem is, complexity grows exponentially with the number of such desisions per function, if they can overlap! (If i'm not mistaken)

> And in any case, I would MUCH prefer a less restrictive language than saving a few clock cycles.

This definately makes sense. But then again, there are 2 fields: high performace numeric code and "inner loops", and the usual roundabout stuff. In inner loops you would usually dispense of all high level stuff which could hinder at optimisation. But i would not like to give up on, say, fixpoint, which is written exactly for the high performance code. On the other hand, direct optimisations on fixpoint are not requiered, since it boils down to integer, where the real job is done. Maybe you're right after all. But Walter has fairly strong opinions you know. Good that he does.

-eye

Ilya Minkov wrote:
>> Or are you saying that the only good use of operator overloading is for a bignum package? That's the only thing I can think of where you need to wrap something with integer-like properties in objects, instead of using the simple integer types.
> 
> 
> You could do a bignum, a fixpoint, and something like a software-steered high-precision floating point. You can also do anything which is a ring. There is an infinite number of rings you know. For example, the polynom ring. And the modulo prime rings.

There is also an infinite number of non-rings ;). I guess my point is that if you limit yourselves to rings you sacrifice a lot of the usefulness of operator overloading.

>> For example, matrices are used a lot in many graphics-intensive programs (games, 3D modelers, etc.), but they follow different rules. Unfortunately, you couldn't implement proper matrix-operators in D :(.
> 
> 
> True. But the a.dot(b) notation is not that bad.

You're right. But being able to write formulas in code as you do on paper can make things more readable. You CAN live without custom operators, but sometimes it is just more convenient to have them. For example, a lot of physicists do not want to use JAVA simply because there are no operator overloads for complex numbers. You have a lot of formulas in simulation programs, and being able to enter them in a readable way is a big advantage.

But I am repeating myself. This argument already took place a few months ago - there's not much sense in doing it all over again.


Hauke