I've accidentally implemented operator overloading in my port.  It was kind of incidental to other work, so I thought "what the hell" and threw it in.  But this brings up the whole issue of syntax, and I think that should be voted on to specify the syntax on my side and to influence Walter when he decides to do this topic.

I'd like Apache-style voting to be used, where the voting is either -1, -0, 0, +0, or +1 for any option, which is a good bellweather of how people think about something.

First off, the naming scheme:

1) "add", "mul", "div", etc.  (my vote: +1)

    Vector mul (Vector b);
    Vector div (Vector b);

2) "op_add", "op_mul", "op_div", etc.  (my vote: +1)

    Vector op_sub (Vector b);
    Vector op_mod (Vector b);

3) "operator +".  (my vote: -1)  My vote is because I find this syntax confusing in C++, particularly with its wide expressiveness, and I admire any syntax which doesn't require a change to tools, as the above don't.

    Vector operator + (Vector b);

4) 'operator "+"'.  (my vote: -0)  For some reason I find this less visually disconcerting.

    Vector operator "*" (Vector b);

5) 'operator (a - b)' or 'operator (this - b)'.  (my vote: +0)  If I had to put in any new syntax I would prefer it to be this one.

    static Vector operator (a - b) (Vector a, Vector b);

Now, where overloaded operators are defined:

1) Operators are normal, possibly virtual methods in classes, normal nonvirtual methods in structs (My vote: +1).

    Vector add (Vector b);

2) Overloaded operators are always static methods with both left and right arguments defined (My vote: 0).

    static Vector add (Vector a, Vector b);

3) Overloaded operators are global functions, using both arguments (My vote: -1).

    Vector add (Vector a, Vector b);

4) Operator overloading shouldn't be put in (My vote: -1).

Now, reverse operator handling, where you want the right-side expression to handle the evaluation, such as with the form "int * Vector":

1) A second set of potential functions (My vote: +1).

2) Automatic reorganization of the expression.  This makes assumptions about what the operators do and can't handle "1 / Vector" (My vote: -1).  For example, "1-A" could become "-A+1".

Now for the operations covered.  Please be temperate with your votes - operations can be added later, but they can't be removed as easily.

1) a + b, a - b, a * b, a / b, a % b, -a, +a.  (my vote: +1)

2) a & b, a | b, a ^ b, ~a, !a.  (my vote: +1)

3) a++, a--, --a, ++a.  (my vote: 0)

4) a = b.  (my vote: 0)

5) a << b, a >> b, a >>> b.  (my vote: +1)

6) a += b, a -= b, a *= b, a %= b, etc.  (my vote: -1)

7) new, delete.  (my vote: -0)

8) a || b, a && b.  (my vote: -1)

9) explicit a >= b, a > b, a <= b, a < b.  (my vote: -1)

10) a [b].  (my vote: +1)

10a) a [b] = c.  (my vote: +0)

11) a [b .. c].  (my vote: +1)

12) &a, *a.  (my vote: -1)

13) a.b, a.b = c.  Retrieve and assign property.  (my vote: +1)  Note that this won't allow just anything in b.

13a) a . b, where b can be any type.  (my vote: -1)

14) a ? b : c.  (my vote: -1)

15) a === b, a !== b.  (my vote: 0)

16) a !<> b, a <> b, a !> b, a !< b, a !<= b, a !>= b.  (my vote: 0) IMO this is an eq/cmp combination issue.

17) a in b.  (my vote: +1)

18) cast (b) a.  (my vote: -0)  I haven't had any good experiences with cast overloading in C++.

19) (a, b).  (my vote: -1)

And miscellaneous:

1) Operator overloading should be allowed on basic types as global functions.  (my vote: -1)

    int operator "a - b" (int a, int b);

2) Definition of new operators is allowed.  I'll ignore this one if it goes positive.  (my vote: -1)

    Vector operator (this dot b) (Vector b);

2a) Setting precedence of new operators is allowed.  I'll ignore this one if it goes positive.  (my vote: -1)

    operator (a dot b) above (a >= b) below (a * b);

I think that's about it.

In general, I am leaning towards using simple names like add, mul, sub, etc. Reverse operations should be addr, mulr, subr, etc. Overloading should be restricted to arithmetic operators, and no assignment operators.

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:3D5278B0.1000508@users.sourceforge.net...
> I've accidentally implemented operator overloading in my port.  It was kind of incidental to other work, so I thought "what the hell" and threw it in.  But this brings up the whole issue of syntax, and I think that should be voted on to specify the syntax on my side and to influence Walter when he decides to do this topic.
>
> I'd like Apache-style voting to be used, where the voting is either -1, -0, 0, +0, or +1 for any option, which is a good bellweather of how people think about something.
>
> First off, the naming scheme:
>
> 1) "add", "mul", "div", etc.  (my vote: +1)
>
>      Vector mul (Vector b);
>      Vector div (Vector b);
>
> 2) "op_add", "op_mul", "op_div", etc.  (my vote: +1)
>
>      Vector op_sub (Vector b);
>      Vector op_mod (Vector b);
>
> 3) "operator +".  (my vote: -1)  My vote is because I find this syntax confusing in C++, particularly with its wide expressiveness, and I admire any syntax which doesn't require a change to tools, as the above don't.
>
>      Vector operator + (Vector b);
>
> 4) 'operator "+"'.  (my vote: -0)  For some reason I find this less
> visually disconcerting.
>
>      Vector operator "*" (Vector b);
>
> 5) 'operator (a - b)' or 'operator (this - b)'.  (my vote: +0)  If I had
> to put in any new syntax I would prefer it to be this one.
>
>      static Vector operator (a - b) (Vector a, Vector b);
>
> Now, where overloaded operators are defined:
>
> 1) Operators are normal, possibly virtual methods in classes, normal
> nonvirtual methods in structs (My vote: +1).
>
>      Vector add (Vector b);
>
> 2) Overloaded operators are always static methods with both left and
> right arguments defined (My vote: 0).
>
>      static Vector add (Vector a, Vector b);
>
> 3) Overloaded operators are global functions, using both arguments (My
> vote: -1).
>
>      Vector add (Vector a, Vector b);
>
> 4) Operator overloading shouldn't be put in (My vote: -1).
>
> Now, reverse operator handling, where you want the right-side expression to handle the evaluation, such as with the form "int * Vector":
>
> 1) A second set of potential functions (My vote: +1).
>
> 2) Automatic reorganization of the expression.  This makes assumptions
> about what the operators do and can't handle "1 / Vector" (My vote: -1).
>   For example, "1-A" could become "-A+1".
>
> Now for the operations covered.  Please be temperate with your votes - operations can be added later, but they can't be removed as easily.
>
> 1) a + b, a - b, a * b, a / b, a % b, -a, +a.  (my vote: +1)
>
> 2) a & b, a | b, a ^ b, ~a, !a.  (my vote: +1)
>
> 3) a++, a--, --a, ++a.  (my vote: 0)
>
> 4) a = b.  (my vote: 0)
>
> 5) a << b, a >> b, a >>> b.  (my vote: +1)
>
> 6) a += b, a -= b, a *= b, a %= b, etc.  (my vote: -1)
>
> 7) new, delete.  (my vote: -0)
>
> 8) a || b, a && b.  (my vote: -1)
>
> 9) explicit a >= b, a > b, a <= b, a < b.  (my vote: -1)
>
> 10) a [b].  (my vote: +1)
>
> 10a) a [b] = c.  (my vote: +0)
>
> 11) a [b .. c].  (my vote: +1)
>
> 12) &a, *a.  (my vote: -1)
>
> 13) a.b, a.b = c.  Retrieve and assign property.  (my vote: +1)  Note
> that this won't allow just anything in b.
>
> 13a) a . b, where b can be any type.  (my vote: -1)
>
> 14) a ? b : c.  (my vote: -1)
>
> 15) a === b, a !== b.  (my vote: 0)
>
> 16) a !<> b, a <> b, a !> b, a !< b, a !<= b, a !>= b.  (my vote: 0)
> IMO this is an eq/cmp combination issue.
>
> 17) a in b.  (my vote: +1)
>
> 18) cast (b) a.  (my vote: -0)  I haven't had any good experiences with
> cast overloading in C++.
>
> 19) (a, b).  (my vote: -1)
>
> And miscellaneous:
>
> 1) Operator overloading should be allowed on basic types as global
> functions.  (my vote: -1)
>
>      int operator "a - b" (int a, int b);
>
> 2) Definition of new operators is allowed.  I'll ignore this one if it
> goes positive.  (my vote: -1)
>
>      Vector operator (this dot b) (Vector b);
>
> 2a) Setting precedence of new operators is allowed.  I'll ignore this
> one if it goes positive.  (my vote: -1)
>
>      operator (a dot b) above (a >= b) below (a * b);
>
> I think that's about it.
>

On Thu, 08 Aug 2002 06:57:04 -0700 Burton Radons <loth@users.sourceforge.net> wrote:

> First off, the naming scheme:
> 
> 1) "add", "mul", "div", etc.  (my vote: +1)
> 
>      Vector mul (Vector b);
>      Vector div (Vector b);

-1

> 2) "op_add", "op_mul", "op_div", etc.  (my vote: +1)
> 
>      Vector op_sub (Vector b);
>      Vector op_mod (Vector b);

-1

> 3) "operator +".  (my vote: -1)  My vote is because I find this syntax confusing in C++, particularly with its wide expressiveness, and I admire any syntax which doesn't require a change to tools, as the above don't.
> 
>      Vector operator + (Vector b);

+0

> 4) 'operator "+"'.  (my vote: -0)  For some reason I find this less visually disconcerting.
> 
>      Vector operator "*" (Vector b);

-0

By the way, what about putting the operator in brackets - (*) rather than "*".
It just seems to look better that way (at least to me). That one would get +1.

> 5) 'operator (a - b)' or 'operator (this - b)'.  (my vote: +0)  If I had to put in any new syntax I would prefer it to be this one.
> 
>      static Vector operator (a - b) (Vector a, Vector b);

0

> Now, where overloaded operators are defined:
> 
> 1) Operators are normal, possibly virtual methods in classes, normal nonvirtual methods in structs (My vote: +1).
> 
>      Vector add (Vector b);

-1

> 2) Overloaded operators are always static methods with both left and right arguments defined (My vote: 0).
> 
>      static Vector add (Vector a, Vector b);

+1

> 3) Overloaded operators are global functions, using both arguments (My vote: -1).
> 
>      Vector add (Vector a, Vector b);

-0

> 4) Operator overloading shouldn't be put in (My vote: -1).

-1 !!!

> Now, reverse operator handling, where you want the right-side expression to handle the evaluation, such as with the form "int * Vector":
> 
> 1) A second set of potential functions (My vote: +1).

+1

> 2) Automatic reorganization of the expression.  This makes assumptions
> about what the operators do and can't handle "1 / Vector" (My vote: -1).
>   For example, "1-A" could become "-A+1".

-1

> Now for the operations covered.  Please be temperate with your votes - operations can be added later, but they can't be removed as easily.
> 
> 1) a + b, a - b, a * b, a / b, a % b, -a, +a.  (my vote: +1)

+1

> 2) a & b, a | b, a ^ b, ~a, !a.  (my vote: +1)

+1

> 3) a++, a--, --a, ++a.  (my vote: 0)

+1

> 4) a = b.  (my vote: 0)

-0

> 5) a << b, a >> b, a >>> b.  (my vote: +1)

+0

> 6) a += b, a -= b, a *= b, a %= b, etc.  (my vote: -1)

-0

> 7) new, delete.  (my vote: -0)

-1

> 8) a || b, a && b.  (my vote: -1)

0

> 9) explicit a >= b, a > b, a <= b, a < b.  (my vote: -1)

+1

> 10) a [b].  (my vote: +1)

+1

> 10a) a [b] = c.  (my vote: +0)

+1

> 11) a [b .. c].  (my vote: +1)

+1

> 12) &a, *a.  (my vote: -1)

-1

> 13) a.b, a.b = c.  Retrieve and assign property.  (my vote: +1)  Note that this won't allow just anything in b.

0

> 13a) a . b, where b can be any type.  (my vote: -1)

-1

> 14) a ? b : c.  (my vote: -1)

-1

> 15) a === b, a !== b.  (my vote: 0)

0

> 16) a !<> b, a <> b, a !> b, a !< b, a !<= b, a !>= b.  (my vote: 0) IMO this is an eq/cmp combination issue.

+1 (it might differ for different argument types: for example, <> is
not just !eq() for fp-numbers).

> 17) a in b.  (my vote: +1)

0

> 18) cast (b) a.  (my vote: -0)  I haven't had any good experiences with cast overloading in C++.

-1 (good for "variant" types but too weird behaviour).

> 19) (a, b).  (my vote: -1)

-1

> And miscellaneous:
> 
> 1) Operator overloading should be allowed on basic types as global functions.  (my vote: -1)
> 
>      int operator "a - b" (int a, int b);

+1 (nothing can be better than overloading operator + for ints in your
friend's program! =)).

Seriously speaking, sometimes you might want to override language
defaults. For example, make it so that int / int produces double
(rather than int).

> 2) Definition of new operators is allowed.  I'll ignore this one if it goes positive.  (my vote: -1)
> 
>      Vector operator (this dot b) (Vector b);

-1

> 2a) Setting precedence of new operators is allowed.  I'll ignore this one if it goes positive.  (my vote: -1)
> 
>      operator (a dot b) above (a >= b) below (a * b);

-1

We should ask C++ experts who write numerical libraries what kind of operator behavior they dream about at night.  (Blitz++ people?)

C++ operators limit what characters/strings can be used to represent an operator function.  I think those choices should be mine to make:  "+special+" should be valid if I want it.

I also might ask whether some kind of multipass compilation in D would facilitate more flexibility with operators.  It would be cool to define a function and then turn it into an operator by adding certain opeartor-ish attributes like "representative symbol string", "precedence level", and "prefix/infix/postfix".  Let alone "associativity" and "commutivity."  Well, sorry for giving you a headache Walter, we will like whatever you do.

Mark

In numerical work one typically prefers classes that know how to hand off pointers to array data, not classes which mandate private internal copies of the data.

STL vectors mandate internal data and it stinks.  Something as harmless as A = B invokes a full array copy behind your back.  STL vector is thus a poor choice for serious numerical work.

I hope that D offers some alternatives here.  STL is quite a disappointment because it almost got there with its iterator and smart pointer concepts.

Mark

Burton Radons <loth@users.sourceforge.net> wrote in news:3D5278B0.1000508 @users.sourceforge.net:


> 
> First off, the naming scheme:
> 
> 1) "add", "mul", "div", etc.  (my vote: +1)
> 
>      Vector mul (Vector b);
>      Vector div (Vector b);

+1

> 
> 2) "op_add", "op_mul", "op_div", etc.  (my vote: +1)
> 
>      Vector op_sub (Vector b);
>      Vector op_mod (Vector b);

+1

> 
> 3) "operator +".  (my vote: -1)  My vote is because I find this syntax confusing in C++, particularly with its wide expressiveness, and I admire any syntax which doesn't require a change to tools, as the above don't.
> 
>      Vector operator + (Vector b);

-1

> 
> 4) 'operator "+"'.  (my vote: -0)  For some reason I find this less visually disconcerting.
> 
>      Vector operator "*" (Vector b);

-0

> 
> 5) 'operator (a - b)' or 'operator (this - b)'.  (my vote: +0)  If I
had
> to put in any new syntax I would prefer it to be this one.
> 
>      static Vector operator (a - b) (Vector a, Vector b);

+0

> 
> Now, where overloaded operators are defined:
> 
> 1) Operators are normal, possibly virtual methods in classes, normal nonvirtual methods in structs (My vote: +1).
> 
>      Vector add (Vector b);

+1

> 
> 2) Overloaded operators are always static methods with both left and right arguments defined (My vote: 0).
> 
>      static Vector add (Vector a, Vector b);

+0

> 
> 3) Overloaded operators are global functions, using both arguments (My vote: -1).
> 
>      Vector add (Vector a, Vector b);

-1

> 
> 4) Operator overloading shouldn't be put in (My vote: -1).

-0

> 
> Now, reverse operator handling, where you want the right-side
expression
> to handle the evaluation, such as with the form "int * Vector":
> 
> 1) A second set of potential functions (My vote: +1).

+1

> 
> 2) Automatic reorganization of the expression.  This makes assumptions about what the operators do and can't handle "1 / Vector" (My vote: -
1).
>   For example, "1-A" could become "-A+1".

-1

> 
> Now for the operations covered.  Please be temperate with your votes - operations can be added later, but they can't be removed as easily.
> 
> 1) a + b, a - b, a * b, a / b, a % b, -a, +a.  (my vote: +1)

+1

What about a ~ b

> 
> 2) a & b, a | b, a ^ b, ~a, !a.  (my vote: +1)

+1

> 
> 3) a++, a--, --a, ++a.  (my vote: 0)

+1

> 
> 4) a = b.  (my vote: 0)

-1

> 
> 5) a << b, a >> b, a >>> b.  (my vote: +1)

+1

> 
> 6) a += b, a -= b, a *= b, a %= b, etc.  (my vote: -1)

+0

> 
> 7) new, delete.  (my vote: -0)

+1

> 
> 8) a || b, a && b.  (my vote: -1)

-1

> 
> 9) explicit a >= b, a > b, a <= b, a < b.  (my vote: -1)

I like cmp as it is

> 
> 10) a [b].  (my vote: +1)

+1

> 
> 10a) a [b] = c.  (my vote: +0)

+1

> 
> 11) a [b .. c].  (my vote: +1)

+1

> 
> 12) &a, *a.  (my vote: -1)

-1

> 
> 13) a.b, a.b = c.  Retrieve and assign property.  (my vote: +1)  Note that this won't allow just anything in b.

+1

> 
> 13a) a . b, where b can be any type.  (my vote: -1)

-1

> 
> 14) a ? b : c.  (my vote: -1)

-1

> 
> 15) a === b, a !== b.  (my vote: 0)

-1

> 
> 16) a !<> b, a <> b, a !> b, a !< b, a !<= b, a !>= b.  (my vote: 0) IMO this is an eq/cmp combination issue.

0

> 
> 17) a in b.  (my vote: +1)

+1

> 
> 18) cast (b) a.  (my vote: -0)  I haven't had any good experiences with cast overloading in C++.

-1

> 
> 19) (a, b).  (my vote: -1)

-1

> 
> And miscellaneous:
> 
> 1) Operator overloading should be allowed on basic types as global functions.  (my vote: -1)
> 
>      int operator "a - b" (int a, int b);

0

Perhaps on typedefs.

> 
> 2) Definition of new operators is allowed.  I'll ignore this one if it goes positive.  (my vote: -1)
> 
>      Vector operator (this dot b) (Vector b);

0

If it was implemented that x.func(y) could be expressed as (x func y)
it might be cool.  However I would set them all to be the same
precedence.

> 
> 2a) Setting precedence of new operators is allowed.  I'll ignore this one if it goes positive.  (my vote: -1)
> 
>      operator (a dot b) above (a >= b) below (a * b);

-1

> 
> I think that's about it.

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:3D5278B0.1000508@users.sourceforge.net...
> I've accidentally implemented operator overloading in my port.  It was kind of incidental to other work, so I thought "what the hell" and threw it in.  But this brings up the whole issue of syntax, and I think that should be voted on to specify the syntax on my side and to influence Walter when he decides to do this topic.
>
> I'd like Apache-style voting to be used, where the voting is either -1, -0, 0, +0, or +1 for any option, which is a good bellweather of how people think about something.
>
> First off, the naming scheme:
>
> 1) "add", "mul", "div", etc.  (my vote: +1)
>
>      Vector mul (Vector b);
>      Vector div (Vector b);

+1

> 2) "op_add", "op_mul", "op_div", etc.  (my vote: +1)
>
>      Vector op_sub (Vector b);
>      Vector op_mod (Vector b);

0

> 3) "operator +".  (my vote: -1)  My vote is because I find this syntax confusing in C++, particularly with its wide expressiveness, and I admire any syntax which doesn't require a change to tools, as the above don't.
>
>      Vector operator + (Vector b);

0

> 4) 'operator "+"'.  (my vote: -0)  For some reason I find this less
> visually disconcerting.
>
>      Vector operator "*" (Vector b);

+1

> 5) 'operator (a - b)' or 'operator (this - b)'.  (my vote: +0)  If I had
> to put in any new syntax I would prefer it to be this one.
>
>      static Vector operator (a - b) (Vector a, Vector b);
>
> Now, where overloaded operators are defined:

+1

> 1) Operators are normal, possibly virtual methods in classes, normal
> nonvirtual methods in structs (My vote: +1).
>
>      Vector add (Vector b);

+1

> 2) Overloaded operators are always static methods with both left and
> right arguments defined (My vote: 0).
>
>      static Vector add (Vector a, Vector b);

-1 (not always)

> 3) Overloaded operators are global functions, using both arguments (My
> vote: -1).
>
>      Vector add (Vector a, Vector b);

-1

>
> 4) Operator overloading shouldn't be put in (My vote: -1).
>
> Now, reverse operator handling, where you want the right-side expression to handle the evaluation, such as with the form "int * Vector":
>
> 1) A second set of potential functions (My vote: +1).

+1

>
> 2) Automatic reorganization of the expression.  This makes assumptions
> about what the operators do and can't handle "1 / Vector" (My vote: -1).
>   For example, "1-A" could become "-A+1".

-1
>
> Now for the operations covered.  Please be temperate with your votes - operations can be added later, but they can't be removed as easily.
>
> 1) a + b, a - b, a * b, a / b, a % b, -a, +a.  (my vote: +1)

+1

> 2) a & b, a | b, a ^ b, ~a, !a.  (my vote: +1)

+1

> 3) a++, a--, --a, ++a.  (my vote: 0)

+1

> 4) a = b.  (my vote: 0)

+1

> 5) a << b, a >> b, a >>> b.  (my vote: +1)

0

> 6) a += b, a -= b, a *= b, a %= b, etc.  (my vote: -1)
>
> 7) new, delete.  (my vote: -0)

-1

> 8) a || b, a && b.  (my vote: -1)

+1

> 9) explicit a >= b, a > b, a <= b, a < b.  (my vote: -1)

+1 (good for sorting ect...)

> 10) a [b].  (my vote: +1)

+1

> 10a) a [b] = c.  (my vote: +0)

0

> 11) a [b .. c].  (my vote: +1)

+1

> 12) &a, *a.  (my vote: -1)

-1

> 13) a.b, a.b = c.  Retrieve and assign property.  (my vote: +1)  Note
> that this won't allow just anything in b.

0

> 13a) a . b, where b can be any type.  (my vote: -1)
-1


> 14) a ? b : c.  (my vote: -1)

-1

> 15) a === b, a !== b.  (my vote: 0)

0 (hummm)

> 16) a !<> b, a <> b, a !> b, a !< b, a !<= b, a !>= b.  (my vote: 0)
> IMO this is an eq/cmp combination issue.

0

> 17) a in b.  (my vote: +1)

+1

> 18) cast (b) a.  (my vote: -0)  I haven't had any good experiences with
> cast overloading in C++.

+1 (Conversion constructor?)

> 19) (a, b).  (my vote: -1)

-1

> And miscellaneous:
>
> 1) Operator overloading should be allowed on basic types as global
> functions.  (my vote: -1)
>
>      int operator "a - b" (int a, int b);

-1

> 2) Definition of new operators is allowed.  I'll ignore this one if it
> goes positive.  (my vote: -1)
>
>      Vector operator (this dot b) (Vector b);

-1

> 2a) Setting precedence of new operators is allowed.  I'll ignore this
> one if it goes positive.  (my vote: -1)
>
>      operator (a dot b) above (a >= b) below (a * b);

0

> I think that's about it.

PS - This will probably be ignored, but I'd also like +,-,* type operators able to be specified as constructors. I'm not say that it should be the only way of specifying overloading because it's ineffecient. I'm just saying that it's conveniant and logical, because in many cases you normally end up creating a new object anyway.

this mul (Vector a, Vector b); //I don't care about the syntax but it
shouldn't be static

"Walter" <walter@digitalmars.com> ha scritto nel messaggio news:aiubuj$2dmc$2@digitaldaemon.com...
> In general, I am leaning towards using simple names like add, mul, sub,
etc.
> Reverse operations should be addr, mulr, subr, etc. Overloading should be restricted to arithmetic operators, and no assignment operators.

Months ago, in an earlier discussion, was advanced the proposal of using _identifiers_ as operators. The proposal was like:

Vector mul (Vector a, Vector b) { ... } // one vector multiplication
Vector vec (Vector a, Vector b) { ... } // the other
...
Vector x = ...;
Vector y = ...;
Vector w = x :mul: y;
Vector z = x :vec: y;

Identifier-operators have all the same precedence and are all left-associative and non-commutative.

I think this is an easy way to use infix notation for nearly everything, and
should be added to D
whether other operator overloading is available or not.

Ciao.

[portions snipped to reduce length]

- Good ideas here is my votes and some comments

Burton Radons wrote:

> First off, the naming scheme:
> 
> 1) "add", "mul", "div", etc.  (my vote: +1)

+0

>2) "op_add", "op_mul", "op_div", etc.  (my vote: +1)

0

>3) "operator +".  (my vote: -1)

-0

> 4) 'operator "+"'.  (my vote: -0)

0

> 5) 'operator (a - b)' or 'operator (this - b)'.

+1

But what if you want to call it as a standard function?

<added>

6) (added) 'sub operator (a-b)' or 'sub operator (this-b)

static Vector sub operator (a - b) (Vector a, Vector b );

+1

</added>

> 1) Operators are normal, possibly virtual methods in classes, normal
> nonvirtual methods in structs (My vote: +1).

+0

> 2) Overloaded operators are always static methods with both left and
> right arguments defined (My vote: 0).

0

> 3) Overloaded operators are global functions, using both arguments (My
> vote: -1).

-0

> 4) Operator overloading shouldn't be put in (My vote: -1).

-1

> 1) A second set of potential functions (My vote: +1).

+0

> 2) Automatic reorganization of the expression.  This makes assumptions
> about what the operators do and can't handle "1 / Vector" (My vote: -1).

-0 (could be useful for error reporting, but a pain to implement)

> 1) a + b, a - b, a * b, a / b, a % b, -a, +a.  (my vote: +1)

+1

> 2) a & b, a | b, a ^ b, ~a, !a.  (my vote: +1)

+1

> 3) a++, a--, --a, ++a.  (my vote: 0)

+0 (but mode (a-- or --a) would be a pain
without type 5) or *6)* style operator defines)

> 4) a = b.  (my vote: 0)

-0

> 5) a << b, a >> b, a >>> b.  (my vote: +1)

+1

> 6) a += b, a -= b, a *= b, a %= b, etc.  (my vote: -1)

-0 (could be useful - but probably better to leave seperate)

> 7) new, delete.  (my vote: -0)

-1 (overloading new & delete is asking for trouble)

> 8) a || b, a && b.  (my vote: -1)

+0

> 9) explicit a >= b, a > b, a <= b, a < b.  (my vote: -1)

+0 (what about NaN in floats etc)

> 10) a [b].  (my vote: +1)

-0

> 10a) a [b] = c.  (my vote: +0)

-1

> 11) a [b .. c].  (my vote: +1)

0

> 12) &a, *a.  (my vote: -1)

-1

> 13) a.b, a.b = c.  Retrieve and assign property.  (my vote: +1)  Note
> that this won't allow just anything in b.

0

> 13a) a . b, where b can be any type.  (my vote: -1)

-0

> 14) a ? b : c.  (my vote: -1)

0 (only possible for syntax types 5) & *6)*

> 15) a === b, a !== b.  (my vote: 0)

-0 (reference compares should remain exactly that - only compare ptr)

> 16) a !<> b, a <> b, a !> b, a !< b, a !<= b, a !>= b.  (my vote: 0)
> IMO this is an eq/cmp combination issue.

+0 (again what about NaN in floats)

> 17) a in b.  (my vote: +1)

+1

> 18) cast (b) a.  (my vote: -0)  I haven't had any good experiences with
> cast overloading in C++.

+0 (there is two types of cast 1. override value (use one bit patten as
another type) and 2. alter value (ie convert from float to int) - although
type 1 should not be overloaded type 2 should - maybe D needs different
syntax for each type of cast?)

> 19) (a, b).  (my vote: -1)

-1

> And miscellaneous:
> 
> 1) Operator overloading should be allowed on basic types as global
> functions.  (my vote: -1)

0 (could be useful - but likely to be misused especially if overloading is global - would only recommend if there were no basic types)

> 2) Definition of new operators is allowed.  I'll ignore this one if it
> goes positive.  (my vote: -1)

+1 (very useful but two issues 1. precidence (how to set - see below) & 2.
syntax / semantic seperation - 2. may be solved by ie prefixing new
operators with a special character ie.
        Vector dot operator (this #dot b ) ( Vector b );
or      Vector dot operator (this #dot# b ) ( Vector b );
)

> 2a) Setting precedence of new operators is allowed.  I'll ignore this
> one if it goes positive.  (my vote: -1)
> 
>      operator (a dot b) above (a >= b) below (a * b);

+1 needed for defining new operators (else set new ops at fixed precidence)
(word "new" is important)

C 2002/8/9

For comments additional format (should be just as easy to parse - and the function name could be optional)

6) (added) 'sub operator (a-b)' or 'sub operator (this-b)

static Vector sub operator (a - b) (Vector a, Vector b );

+1

EBNF (elc) ->
`` assumes function name is optional

operatorOverloadFunction
:       [ "static" ] type [ Identifier ] "operator"
                "(" form ")" "(" [ arguments ] ")"
;

form
:       operator Identifier
|       Identifier operator Identifier
|       Identifier operator
;

C 2002/8/9