• Roland (21/21) Aug 27 2001 I assume D don't have operator overloading.
• Brendan Wright (5/10) Aug 30 2001 I wouldn't honestly know about much about what hassles this sort of thin...
• Brent Schartung (9/16) Aug 30 2001 Careful. I think we're straying dangerously close to "function objects"...
• Dan Hursh (43/58) Aug 30 2001 I don't think the issue is whether or not it can be done. In C++ (the
• Brendan Wright (11/52) Aug 31 2001 phew! I'm not really the expert on this one either. Less expert than you...
• Russ Lewis (6/9) Aug 31 2001 This is a good thing to remember. It is (comparatively) easy to retrofi...
• Charles Hixson (22/29) Sep 05 2001 eeeep! Not very nice at all. Operators should be clearly demarkated
• Roland (13/50) Sep 05 2001 for me 'm3 = m1 plus m2;' is recognizable enough.
• Russ Lewis (10/23) Sep 05 2001 Using infix words is nice in your example, but I think that it will tend...
• Roland (14/23) Sep 06 2001 i tried to translate
Roland <rv ronetech.com> writes:
```I assume D don't have operator overloading.

too bad, how will i do with my vectors and matrixs ?

i will have to translate declaration:

Matrix operator+(Matrix& m1, Matrix& m2);

executed:

Matrix m1,m2,m3;
m3 = m1+m2;

to declaration:

Matrix plus(Matrix& m1, Matrix& m2);

executed:

Matrix m1,m2,m3;
m3 = plus(m1,m2);

not very nice..

now imagine 'plus' function could be called like this:

m3 = m1 plus m2;

better isn't it ?
is technicaly possible ?

Regards

Roland
```
Aug 27 2001
"Brendan Wright" <brendan_wright hotmail.com> writes:
``` now imagine 'plus' function could be called like this:

m3 = m1 plus m2;

better isn't it ?
is technicaly possible ?

I wouldn't honestly know about much about what hassles this sort of thing
could introduce, but for 3D work etc it sure would make code heaps nicer and
cleaner!! I hope something can be done to implement some form of operator

-Brendan
```
Aug 30 2001
"Brent Schartung" <bschartung home.com> writes:
```Careful.  I think we're straying dangerously close to "function objects",
one of the most obscure features of C++ (IMHO of course).  For the
uninitiated, it's a class with operator() defined; i.e. less::operator()
(char*t,int n); --I think that's right--so you can pass it to a template,
for example.  Say you define a less class that operates on two of your
classes; you'd use that less class to create a sorting template class.
Weird?

Possibly useful, definitely one of the dustier corners of the language.

Brent

now imagine 'plus' function could be called like this:

m3 = m1 plus m2;

better isn't it ?
is technicaly possible ?

```
Aug 30 2001
Dan Hursh <hursh infonet.isl.net> writes:
```Brendan Wright wrote:

now imagine 'plus' function could be called like this:

m3 = m1 plus m2;

better isn't it ?
is technicaly possible ?

I wouldn't honestly know about much about what hassles this sort of thing
could introduce, but for 3D work etc it sure would make code heaps nicer and
cleaner!! I hope something can be done to implement some form of operator

-Brendan

I don't think the issue is whether or not it can be done.  In C++ (the
has caused a number of problems.  The question is can it be done
better.  Walter has addressed some of the more common uses of operator
me at the moment).
Like you, I agree that overloading is a good thing, because I like to
do 3D math on occasion.  Even if D did include a way of doing 3D math,
I've found that in other languages that there are tradeoffs that can be
made on implementation, so it is not likely that D will find the one
true way that is good (or even reasonable) in all imaginable cases.  (I
could be wrong.)  So a library should do it, but a library can only
prove a procedural interface when infix is much more appropriate.
That is not a reason to just cop out and pick a sorry implementation
see a few problems with progress here.
1) there is one Walter, and his hands are full.
it is hardly a show stopper for D.  I would hold out
of a later version to review this.
3) In order to fix the problems, we would need a good formal
statement of the problems.  I personally am too biased in
4) formally state the desired function.  For me it is a lot more
string concatenation.  I haven't really gotten my head around
this myself, so I haven't pushed it.

For me I think it boils down to wanting my own infix operations for
certain types.  I haven't been able to justify the need for the regular
operators used on built-ins, except for in the case of writing generic
functions that can operate on both built-ins and ADT's with infix ops.
Since D doesn't have an answer for generic programming either, it's
premature to use that argument.
I like the idea for writing my own first class objects, but C++ didn't
exactly get that right either, so it is hard to argue from that
perspective.  Since D doesn't not seem interested in wandering down the
road of reflectiveness, I don't really have any good arguments.

I would like to hear some of the good reasons against operator
overloading.  "I don't like it", "C++ did it wrong so it sucks" and "I
shot myself in the foot with it" don't count.  How you shot yourself is
valid.  Exactly how C++ got it wrong is valid too.  Personal ascetics
can go either way depend on the reasons.

Dan
```
Aug 30 2001
"Brendan Wright" <brendan_wright hotmail.com> writes:
``` I don't think the issue is whether or not it can be done.  In C++ (the
has caused a number of problems.  The question is can it be done
better.  Walter has addressed some of the more common uses of operator
me at the moment).
Like you, I agree that overloading is a good thing, because I like to
do 3D math on occasion.  Even if D did include a way of doing 3D math,
I've found that in other languages that there are tradeoffs that can be
made on implementation, so it is not likely that D will find the one
true way that is good (or even reasonable) in all imaginable cases.  (I
could be wrong.)  So a library should do it, but a library can only
prove a procedural interface when infix is much more appropriate.
That is not a reason to just cop out and pick a sorry implementation
see a few problems with progress here.
1) there is one Walter, and his hands are full.
it is hardly a show stopper for D.  I would hold out
of a later version to review this.
3) In order to fix the problems, we would need a good formal
statement of the problems.  I personally am too biased in
4) formally state the desired function.  For me it is a lot more
string concatenation.  I haven't really gotten my head around
this myself, so I haven't pushed it.

For me I think it boils down to wanting my own infix operations for
certain types.  I haven't been able to justify the need for the regular
operators used on built-ins, except for in the case of writing generic
functions that can operate on both built-ins and ADT's with infix ops.
Since D doesn't have an answer for generic programming either, it's
premature to use that argument.
I like the idea for writing my own first class objects, but C++ didn't
exactly get that right either, so it is hard to argue from that
perspective.  Since D doesn't not seem interested in wandering down the
road of reflectiveness, I don't really have any good arguments.

I would like to hear some of the good reasons against operator
overloading.  "I don't like it", "C++ did it wrong so it sucks" and "I
shot myself in the foot with it" don't count.  How you shot yourself is
valid.  Exactly how C++ got it wrong is valid too.  Personal ascetics
can go either way depend on the reasons.

phew! I'm not really the expert on this one either. Less expert than you it
clean I guess, op. overloading seems to kind of hide a lot of what is really
going on - possibly not a good thing when it cames to making a nice simple
high-performing language. Perhaps we could start an underground movement to
procedural or whatever. Because there must be a level at which you can do a
simple "operator -> two input function call" conversion without getting
involved in Dangerous Tricky Things. But then again, maybe I just don't
understand the issues... :-)

-Brendan
```
Aug 31 2001
Russ Lewis <russ deming-os.org> writes:
```Dan Hursh wrote:

it is hardly a show stopper for D.  I would hold out
of a later version to review this.

This is a good thing to remember.  It is (comparatively) easy to retrofit
operator
some poorly designed version now, that design will have a lot of inertia (to
support old code).  Let's leave questionable features out for now and help
Walter
get the compiler out *yesterday*.
```
Aug 31 2001
```Roland wrote:

...  now imagine 'plus' function could be called like this:

m3 = m1 plus m2;

better isn't it ? is technicaly possible ? if yes, no need for

Regards

Roland

eeeep!  Not very nice at all.  Operators should be clearly demarkated
from the rest of the language, distinguishable at a glance.  The alter
the order of invocation.  Now in FORTH there are fancy things that
appear to be operators, but actually act quite differently, but even in
that foot-loose language there tends to be a clear syntactic marker used
to differentiate those words from the others.  (I can't remember what it
is anymore.  Either they begin with a period or end with a colon or some
such.  It's purely a convention, but it's so necessary for the language
to be understood that it tends to be adhered to even though anyone can
define any word of any kind that they choose.  Or even redefined words
standardly defined in the system.)

I prefer something simple, like :+: or :plus:, but note the boundary
markers.  This would make them distinguishable at a glance.  And I think
that this would be important.  These are actually just method calls with
sugar, i.e., a :+: b == a.:+:(b), there shouldn't be much compiler
overhead, and I feel that they should be a overloadable as any other
method.  But I am not arguing that the standard operators should be
overloadable.  They may have special compiler optimizations, etc.  But I
think that user definable operators are desireable, and that they should
syntax class easily recognizable.
```
Sep 05 2001
Roland <rv ronetech.com> writes:
```Charles Hixson a écrit :

Roland wrote:

> ...  now imagine 'plus' function could be called like this:
>
> m3 = m1 plus m2;
>
> better isn't it ? is technicaly possible ? if yes, no need for
>
> sorry for my bad english
>
> Regards
>
> Roland
>
eeeep!  Not very nice at all.  Operators should be clearly demarkated
from the rest of the language, distinguishable at a glance.  The alter
the order of invocation.  Now in FORTH there are fancy things that
appear to be operators, but actually act quite differently, but even in
that foot-loose language there tends to be a clear syntactic marker used
to differentiate those words from the others.  (I can't remember what it
is anymore.  Either they begin with a period or end with a colon or some
such.  It's purely a convention, but it's so necessary for the language
to be understood that it tends to be adhered to even though anyone can
define any word of any kind that they choose.  Or even redefined words
standardly defined in the system.)

I prefer something simple, like :+: or :plus:, but note the boundary
markers.  This would make them distinguishable at a glance.  And I think
that this would be important.  These are actually just method calls with
sugar, i.e., a :+: b == a.:+:(b), there shouldn't be much compiler
overhead, and I feel that they should be a overloadable as any other
method.  But I am not arguing that the standard operators should be
overloadable.  They may have special compiler optimizations, etc.  But I
think that user definable operators are desireable, and that they should
syntax class easily recognizable.

for me 'm3 = m1 plus m2;' is recognizable enough.

- it hides computation time too much,
- you can't make a find on '+' word as it will find you overloaded operator
and normal one as well.

when i read 'm3 = m1 plus m2' i know:
- m1 or m2 or both are classes,
- 'plus' is a function i wrote and i can make a find on its name.
personally don't need any more.

i think Brent Schartung argument:
Careful.  I think we're straying dangerously close to "function objects",
one of the most obscure features of C++

is better if D implements function objects.

Roland
```
Sep 05 2001
Russ Lewis <russ deming-os.org> writes:
```Roland wrote:

for me 'm3 = m1 plus m2;' is recognizable enough.

- it hides computation time too much,
- you can't make a find on '+' word as it will find you overloaded operator
and normal one as well.

when i read 'm3 = m1 plus m2' i know:
- m1 or m2 or both are classes,
- 'plus' is a function i wrote and i can make a find on its name.
personally don't need any more.

i think Brent Schartung argument:
Careful.  I think we're straying dangerously close to "function objects",
one of the most obscure features of C++

is better if D implements function objects.

Using infix words is nice in your example, but I think that it will tend to
suffer from 'PERL syndrome' (so much syntax flexibility that the code is nearly
impossible to read).  This might also be legal:

var1 each word in this line is another operator but which ones do what var2;

Which would also be legal.

I really like operator overloading in C++, but I understand that it may be too

I have a ponder...but it's OT enough I'm going to start a new thread about it.
Look for 'externally processed blocks'.
```
Sep 05 2001
Roland <rv ronetech.com> writes:
```Russ Lewis a écrit :

Roland wrote:

for me 'm3 = m1 plus m2;' is recognizable enough.

Using infix words is nice in your example, but I think that it will tend to
suffer from 'PERL syndrome' (so much syntax flexibility that the code is nearly
impossible to read).  This might also be legal:

var1 each word in this line is another operator but which ones do what var2;

Which would also be legal.

i tried to translate

var1 each word in this line is another operator but which ones do what var2;

replace 'each' by '+', 'word' by '-', 'in' by '/' ..'what' by '*', you have
something like

var1 +-/..* var2;

not legal in C++

an other way is to translate like this (all one argument operator exept 'each'):

each(var1,
word(in(this(line(is(another(operator(but(which(ones(do(what(var2)))))))))))));

witch is less clear than

var1 each word in this line is another operator but which ones do what var2;

Look for 'externally processed blocks'.

i will

Roland
```
Sep 06 2001