Walter wrote:

> I'm looking at the overloading of commutative operators add, multiply, etc. There are a couple of options for dealing with the (1 + a) case:
>
> 1) Provide a separate "add_r" function to make a.add_r(1)
> 2) Allow the compiler to swap the operands and call a.add(1)
> 3) Allow the compiler to swap the operands unless there is an "add_r"
> function defined.

and then Burton Radons wrote:

> It's not really worth the gain when you can write out a basic reverse with one line:
>
> Vector operator (extended a) + (Vector b) { return b + a; }
> Vector operator (extended a) - (Vector b) { return -b + a; }
> Vector operator (extended a) * (Vector b) { return b * a; }

In earlier postings there was some discussion as to what syntax operator
overloading should have. It seems from above that a solution as not been
reached:

   Vector operator (extended a) + (Vector b);
   Vector add(a);

What are the results of the "Operator Overloading Vote" posting?
Is operator overloading syntax still open for votes?
Have any decisions been made regarding the syntax?

It would be terrible if different implementations of D implemented operator
overloading differently.

Jason

"Walter" <walter@digitalmars.com> wrote in news:ajk6mq$2o08$1@digitaldaemon.com:

> I'm looking at the overloading of commutative operators add, multiply, etc. There are a couple of options for dealing with the (1 + a) case:
> 
> 1) Provide a separate "add_r" function to make a.add_r(1)
> 2) Allow the compiler to swap the operands and call a.add(1)
> 3) Allow the compiler to swap the operands unless there is an "add_r"
> function defined.
> 
> I'm leaning towards (2), it is simpler and in keeping with the way the
> builtin operators work. Note that this would only apply to those
> operators that are mathematically commutative. It does not allow
> associative rearrangement, and does not allow replacing (a - b) with
> (a + (-b)), etc.
> 
> 

Number 2 works in a lot of cases.

1. It's true that for at least the math systems I use
operations with basic types (int,float) are commutative.
However I'm not a mathmation so I don't know if this
is universally true.

2. The author of some math libary can make sure that all the types that are not commutative have left associative operators.  i.e

class A { A mul(B b) { } }
class B ( B mul(A a) { } }

The problem comes when some other programmer now wants to extend the math libary with type C.  With the the reverse operators he can get it to work.

class C
{
  C mul(A a) { }
  A mul_r(C c) { }
}

So I'm inclined to vote for option #3.

"Jason Mills" <jmills@cs.mun.ca> wrote in message news:20020817.135143.339834416.5441@localhost.localdomain...
> It would be terrible if different implementations of D implemented
operator
> overloading differently.

I've got it mostly implemented now, stay tuned! Of course, with all the conflicting ideas on it, it's a sure thing that not everyone will be pleased, but I think what I've got will address what operator overloading is needed for in a simple, easy-to-understand manner.

I'm sure what ever you come up with will be brilliant. Operator Overloading is i no better hands.

"Walter" <walter@digitalmars.com> wrote in message news:ajlssa$1qds$1@digitaldaemon.com...
>
> "Jason Mills" <jmills@cs.mun.ca> wrote in message news:20020817.135143.339834416.5441@localhost.localdomain...
> > It would be terrible if different implementations of D implemented
> operator
> > overloading differently.
>
> I've got it mostly implemented now, stay tuned! Of course, with all the conflicting ideas on it, it's a sure thing that not everyone will be pleased, but I think what I've got will address what operator overloading
is
> needed for in a simple, easy-to-understand manner.
>
>

"anderson" <anderson@firestar.com.au> wrote in message news:ajn6ar$12j$1@digitaldaemon.com...
> I'm sure what ever you come up with will be brilliant. Operator
Overloading
> is i no better hands.

Thanks for the vote of confidence. I want the result to wind up being so obvious that people will think "of course, there's no magic there, I could have done that myself!" The hardest engineering thing in the world to do is come up with something simple and obvious.

It's all too easy to come up with something complicated :-(

"Walter" <walter@digitalmars.com> wrote in message news:ajncr4$7n2$2@digitaldaemon.com...
>
> "anderson" <anderson@firestar.com.au> wrote in message news:ajn6ar$12j$1@digitaldaemon.com...
> > I'm sure what ever you come up with will be brilliant. Operator
> Overloading
> > is i no better hands.
>
> Thanks for the vote of confidence. I want the result to wind up being so obvious that people will think "of course, there's no magic there, I could have done that myself!" The hardest engineering thing in the world to do
is
> come up with something simple and obvious.
>
> It's all too easy to come up with something complicated :-(
>


Yes, brilliance doesn't mean things need to be complicated. Brilliance often makes things easier for others.

The language is still alpha anyway so now is the perfect time to experiment with different syntaxes.  And I'm sure once we begin to use it, any flaws will present themselves promptly.

Please nobody start using operator overloading yet unless you're willing to throw the code away and start over once the final syntax is established.

It seems Burton is going in a good direction so far.  I'm just surprised Walter is on board with it.  ;)   I'm glad all those huge threads weren't in vain.

Sean

"Walter" <walter@digitalmars.com> wrote in message news:ajlssa$1qds$1@digitaldaemon.com...
>
> "Jason Mills" <jmills@cs.mun.ca> wrote in message news:20020817.135143.339834416.5441@localhost.localdomain...
> > It would be terrible if different implementations of D implemented
> operator
> > overloading differently.
>
> I've got it mostly implemented now, stay tuned! Of course, with all the conflicting ideas on it, it's a sure thing that not everyone will be pleased, but I think what I've got will address what operator overloading
is
> needed for in a simple, easy-to-understand manner.

Speaking of **, are there any plans for D to support exponentiation?  It's such a basic math function...

Neither ** nor ^ are good choices for operator since ^ already means xor and a ** b can be mistaken for a * (*b).

I guess there's always pow()...

Sean

"anderson" <anderson@firestar.com.au> wrote in message news:ajl71t$14of$1@digitaldaemon.com...
> Come to think of it....
>
> How will...
>
> Matrix ** Integer
>
> be handled?

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:ajnom1$kfq$1@digitaldaemon.com...
> Speaking of **, are there any plans for D to support exponentiation?  It's such a basic math function...
>
> Neither ** nor ^ are good choices for operator since ^ already means xor
and
> a ** b can be mistaken for a * (*b).
>
> I guess there's always pow()...

I've always been partial to FORTRAN's exponentiation operator, but it doesn't fit in well with all the other operators C/C++/D has. pow() is ugly, but it does work.

On Sun, 18 Aug 2002 02:25:01 -0700 "Sean L. Palmer" <seanpalmer@earthlink.net> wrote:

> Speaking of **, are there any plans for D to support exponentiation?  It's such a basic math function...
> 
> Neither ** nor ^ are good choices for operator since ^ already means xor and a ** b can be mistaken for a * (*b).
> 
> I guess there's always pow()...

Hm... Maybe a^^b?