I'd be just fine with this:

Vector operator(Vector a - Vector b)
{
    return a.sub(b);
}

Vector operator(-Vector a)
{
    return a.negate();
}

operators only permitted at module scope.

I too would like to see

Vector operator(Vector a dot Vector b)
{
    return a.dot(b);
}

It should be easy enough to parse the declarations out separately from the operator symbols.

Sean

"C.R.Chafer" <blackmarlin@nospam.asean-mail.com> wrote in message news:aj08qk$1qc3$1@digitaldaemon.com...
> 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

"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

It's unnecessary.  If you want it to call a mul function, have the operator call it.  Otherwise you can put all the code into the operator.

> 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

Screw the tools.  Tools can change;  it's early enough in the D lifecycle.

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

-0   (Mainly it shouldn't be a member function)

> 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);

+1

Although the static keyword is unnecessary;  they should be able to be defined at global scope.  Also the (a - b) part and (Vector a, Vector b) part should be able to be combined into one, something like:

Vector operator ( (Vector a) - (Vector b) ) { return a.sub(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);

-1 (though they can *call* methods)

> 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  (except for unary operators which have only one argument)

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

-99   ;)   (ok, really -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".

-0

This could break some code.

> 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)

+0

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

+1

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

+0   (This is really useful sometimes in C++, but I can live without it)

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

+0

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

+1

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

+0  (I'd like some way to change allocation for a class, but not sure overriding new and delete is the best answer.   Maybe flag the class as having a special allocator?)

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

-0

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

+1  but it sure would be nice if you didn't have to provide them all (if you override a == b and a < b, it can generate all the other ones automatically)

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

+1   (how else will you make custom containers?)

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

+0   (this needs thought out more, but overriding assignment is useful
sometimes)

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

+1  what the hell

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

-0

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

+0  existing property syntax handles this.  Do you mean it can pass b in as a string?

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

-1

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

-1  not needed, confusing

> 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  I would only allow overriding == and <

> 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   me neither

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

-1  even though  I've seen this put to good use in Spirit.

> 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  So long as it's done through modules and doesn't automatically affect the entire program.  It would be useful occasionally (rarely)

> 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   would be very nice, but hard to implement.  I'd like to allow high unicode symbols.

> 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   would be nice, but it's hard to implement.

> I think that's about it.

Sean

(Although the rope class may be something like what is required...reference counted and all that...M.)

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

y = Vector.mul(x); // should be allowed.

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

-0  Why not opAdd or OpMul or operatorAdd ?

> 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

This do not increase parser complexity. * is a token but "*" should be a token or a string. If a string, when it need to be interpreted?

> 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);

-1

add new semantic problems: Vector operator (x - y) (Vector a, Vector b);
and is similar to Vector operator + (Vector b); only with duplicated
parameters.


> 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

Compared with (3), what this add ? Only the position of coding (within the class). But you could not make a additional operations module for another person module. But why separate? if you don't want maintaing that code but you trust in that person. if you need sync and dont wanna make modifications for that code (bug corrections).

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

-0

This could be added later if are needs. And should be consistent with overloading for non-object types.


> 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.

I tend to agree with you. except in:

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

There are good questions here.
1) a = b + 1;  // a and b are the same type

is :

a.replacedby(b.add(1));

or

result = new resultype();  // similar with the above
result.add(1);
a.replacedby(result);
delete result;

or

a.replacedby(b);
a.add(1);

2) a = a + 1;

is above or:

a.add(1);


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

What the diference between the properties defined by Walter where a property is a simply procedure or function ?

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

casting should be explicited in code :

int a;
currency x;

a + x; // error
a + cast(int) x; // ok

If casting and assignment don't be allowed, for what uses op overloading
could be used?
I know this is problematic. But could have a restricted version of both.

> 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
    	For using with high performance computing like Currency, DateTime,
Matematical calculations, ...
    	This could not override built-in defined operations. Than one of
operands _must_ be typedef'ed.

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

    	And this follows the previous naming scheme:

    	int add(myType 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);

-0

> 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 If this will not be allowed now, this could be allowed later.


    	Maybe could be a good decision stay with a little set of features
allowing to be increased in future versions of language when the use
could be justified by the need.

-jr

Perhaps helpful ideas:

http://www.boost.org/libs/utility/operators.htm

Mark

> 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

Because we are dealing with a Vector-Vector relationship this makes sense, however ...

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

+1

Here we are dealing with relationships, not things specific to any particular object.  Operator overloading actually fits the object-relational paradigm better than the object-oriented paradigm.  I know OOP purists consider "global" to be morally wrong.  But, tell me, to which object does this relationship belong?

Vector mul (Vector a, Matrix b);

We have a few options.  We can put this relationship in the Vector class or we can put in the Matrix class.  It's really not entirely clear where it belongs.  But it makes more sense to me to define it outside of any class because it doesn't fit the OOP paradigm because it is a relationship between two objects.  I'm sorry to burst you OOP purist bubble. Relationships do not fit OOP.  Relationships fit the object-relational paradigm.  Dare I say the word "multimethods"?  Just my two very educated cents.

Thanks for listening.

Craig

"Roberto Mariottini" <rmariottini@lycosmail.com> wrote in message news:aj03sh$1lar$1@digitaldaemon.com...
>
> "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.

It's a good idea, it would be interesting to see how readable it looks in a non-trivial situation.

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:3D5278B0.1000508@users.sourceforge.net...
> 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".

It just occurred to me (I apologize if I missed someone else posting it) that the language can make the commutative operators (+, *, |, &, etc.) commutative even with operator overloads, with the proviso that if a reverse overload was provided, that would be used instead. For example:

class A
{
    A add(int);
}

A a;
a+1 => a.add(1)
1+a => a.add(1)

But if:

class A
{
    A add(int);
    A add_r(int);
}

A a;
a+1 => a.add(1)
1+a => a.add_r(1)

This seems to have the advantage of both schemes, and minimizes the need for a plethora of functions being defined just for swizzling the arguments.

You do have a good point.

"cblack01" <cblack01@cox.net> wrote in message news:aj4glg$e61$1@digitaldaemon.com...
> > 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
>
> Because we are dealing with a Vector-Vector relationship this makes sense, however ...
>
> > 3) Overloaded operators are global functions, using both arguments (My
> > vote: -1).
> >
> >    Vector add (Vector a, Vector b);
>
> +1
>
> Here we are dealing with relationships, not things specific to any particular object.  Operator overloading actually fits the
object-relational
> paradigm better than the object-oriented paradigm.  I know OOP purists consider "global" to be morally wrong.  But, tell me, to which object does this relationship belong?
>
> Vector mul (Vector a, Matrix b);
>
> We have a few options.  We can put this relationship in the Vector class
or
> we can put in the Matrix class.  It's really not entirely clear where it belongs.  But it makes more sense to me to define it outside of any class because it doesn't fit the OOP paradigm because it is a relationship
between
> two objects.  I'm sorry to burst you OOP purist bubble. Relationships do
not
> fit OOP.  Relationships fit the object-relational paradigm.  Dare I say
the
> word "multimethods"?  Just my two very educated cents.
>
> Thanks for listening.
>
> Craig
>
>
>
>
>

Right, but what about?

class A
{
    A add(B);
    A add_r(B);
}

class B
{
    B add(A);
    B add_r(A);
}

I suppose this may be illegal?

A a;
B b;
a+b => a.add(b) & b.add(a)
b+a => a.add_r(b) & b.add_r(a)


"Walter" <walter@digitalmars.com> wrote in message news:aj6gbt$2c7b$1@digitaldaemon.com...
>
> "Burton Radons" <loth@users.sourceforge.net> wrote in message news:3D5278B0.1000508@users.sourceforge.net...
> > 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".
>
> It just occurred to me (I apologize if I missed someone else posting it) that the language can make the commutative operators (+, *, |, &, etc.) commutative even with operator overloads, with the proviso that if a
reverse
> overload was provided, that would be used instead. For example:
>
> class A
> {
>     A add(int);
> }
>
> A a;
> a+1 => a.add(1)
> 1+a => a.add(1)
>
> But if:
>
> class A
> {
>     A add(int);
>     A add_r(int);
> }
>
> A a;
> a+1 => a.add(1)
> 1+a => a.add_r(1)
>
> This seems to have the advantage of both schemes, and minimizes the need
for
> a plethora of functions being defined just for swizzling the arguments.
>
>
>