www.digitalmars.com         C & C++   DMDScript  

D - Operator Overloading Syntax Idea

reply J C Calvarese <jcc7 cox.net> writes:
Hi everyone.

I don't know much about operator overloading, but I think D can have 
better syntax.  I think some of the current abbreviations are less than 
intuitive and tough to remember.  I'd like for D to have a syntax that 
is pretty self-explanatory.  Also, some of the current symbols seem sort 
of unappealing (addass, catass, orass).  D hasn't reached the 
all-important status of 1.00, so I'll throw out my ideas...


Current		Proposal

neg		operator[-u]
com		operator[~u]
postinc 	operator[++u]
add		operator[+]
sub		operator[-]
sub_r		operator[-r]
cat		operator[~]
addass  	operator[+=]
eq		operator[==]
cmp		operator[<]
orass		operator[|=]
catass		operator[~=]
opCall		operator[()]
opIndex		operator[i]
opSlice		operator[..]

u: unary
r: reverse
i: index

If "operator" seems too verbose, "op" or "opfunc" might be more suitable.



Examples:

class A { int operator[-u](); }

b.operator[-r](a)



Justin
http://jcc_7.tripod.com/d/
Nov 10 2003
parent reply davepermen <davepermen_member pathlink.com> writes:
more important imho: operators should not need to be member functions. that way,
you could add an own operator<< for your stream like in c++.. or operator(), or
what ever:D

how ever D wants to make their streams, stdin, stdout, and filestuff, we will
never get it flexible and extendable without function operators.

i for myself like operator add instead of opAdd..

In article <bopknf$2n32$1 digitaldaemon.com>, J C Calvarese says...
Hi everyone.

I don't know much about operator overloading, but I think D can have 
better syntax.  I think some of the current abbreviations are less than 
intuitive and tough to remember.  I'd like for D to have a syntax that 
is pretty self-explanatory.  Also, some of the current symbols seem sort 
of unappealing (addass, catass, orass).  D hasn't reached the 
all-important status of 1.00, so I'll throw out my ideas...


Current		Proposal

neg		operator[-u]
com		operator[~u]
postinc 	operator[++u]
add		operator[+]
sub		operator[-]
sub_r		operator[-r]
cat		operator[~]
addass  	operator[+=]
eq		operator[==]
cmp		operator[<]
orass		operator[|=]
catass		operator[~=]
opCall		operator[()]
opIndex		operator[i]
opSlice		operator[..]

u: unary
r: reverse
i: index

If "operator" seems too verbose, "op" or "opfunc" might be more suitable.



Examples:

class A { int operator[-u](); }

b.operator[-r](a)



Justin
http://jcc_7.tripod.com/d/

Nov 11 2003
parent reply "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
 more important imho: operators should not need to be member functions.

 you could add an own operator<< for your stream like in c++.. or

 what ever:D

Absolutely. This is very important. Non-member functions increase encapsulation. :) An additional benefit of such a thing is that they would not need to be virtual.
 how ever D wants to make their streams, stdin, stdout, and filestuff, we

 never get it flexible and extendable without function operators.

 i for myself like operator add instead of opAdd..

Nov 11 2003
parent reply "Achilleas Margaritis" <axilmar b-online.gr> writes:
"Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
news:borbm8$28gn$1 digitaldaemon.com...
 more important imho: operators should not need to be member functions.

 you could add an own operator<< for your stream like in c++.. or

 what ever:D

Absolutely. This is very important. Non-member functions increase encapsulation. :) An additional benefit of such a thing is that they would not need to be virtual.
 how ever D wants to make their streams, stdin, stdout, and filestuff, we

 never get it flexible and extendable without function operators.

 i for myself like operator add instead of opAdd..


How about declaring operators as normal functions ? like this: class MyClass { public MyClass = (MyClass obj) { //TODO } public MyClass += (int i) { //TODO } } Etc...no need for special syntax or anything. Operators could also be declared outside of a class: MyClass += (MyClass a, MyClass b) { //TODO return a; } It would also be very useful to be able to declare our own operators. Operators are just syntactic sugar anyway. For example: operator int x(int a, int b) { return a * b; } usage: int b = 10 x 50;
Nov 11 2003
next sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Achilleas Margaritis wrote:

"Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
news:borbm8$28gn$1 digitaldaemon.com...
  

more important imho: operators should not need to be member functions.
      

you could add an own operator<< for your stream like in c++.. or
      

what ever:D
      

encapsulation. :) An additional benefit of such a thing is that they would not need to be virtual.
how ever D wants to make their streams, stdin, stdout, and filestuff, we
      

never get it flexible and extendable without function operators.

i for myself like operator add instead of opAdd..
      


How about declaring operators as normal functions ? like this: class MyClass { public MyClass = (MyClass obj) { //TODO } public MyClass += (int i) { //TODO } } Etc...no need for special syntax or anything. Operators could also be declared outside of a class: MyClass += (MyClass a, MyClass b) { //TODO return a; } It would also be very useful to be able to declare our own operators. Operators are just syntactic sugar anyway. For example: operator int x(int a, int b) { return a * b; } usage: int b = 10 x 50;

I've got an odd feeling that most of these ideas where suggested when operators where being developed for D (and I'm not just talking about this particular suggestion). Parhaps the newsgroup archives deserve a re-visit :d -Anderson
Nov 11 2003
parent reply davepermen <davepermen_member pathlink.com> writes:
In article <borqtm$2vdr$1 digitaldaemon.com>, J Anderson says...
I don't want to shoot your idea down or anything but...
I've got an odd feeling that most of these ideas where suggested when 
operators where being developed for D (and I'm not just talking about 
this particular suggestion).  Parhaps the newsgroup archives deserve a 
re-visit :d

-Anderson

i don't think you shoot down anything. except one: D has, after possibly long discussions, some way to overload operators. now, that you can use it, people start to realise that it behaves rather wrong. i'm rather new to D, so i wasn't around then. i would have cried right then, that this way will not be the way that makes them useful. operators (talking now about binary ones), act on two objects, with equal importance. there is no rule that can say wich one has to be the object that provides the operator. the operator has to be free of the objects. that way, operators can get loose bindings to all sort of type operations. just as its possible in c++. just as it gets most used in c++ actually. f.e. for streams. where you can add new types to the stream operator simply.. T op (A a,B b) { return op_operation(a,b); } A a; B b; T t = a op b; that way, it would be VERY useful.. vec3 + (vec3 a,vec3 b) { return vec3.add(a,b); } that style..
Nov 11 2003
parent reply "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
I'm pretty sure that a search of the archives will reveal that the only
person who is happy with having binary operators as member functions is the
one who's writing the compiler. The rest of us are quite unhappy about it

"davepermen" <davepermen_member pathlink.com> wrote in message
news:borrq4$30q3$1 digitaldaemon.com...
 In article <borqtm$2vdr$1 digitaldaemon.com>, J Anderson says...
I don't want to shoot your idea down or anything but...
I've got an odd feeling that most of these ideas where suggested when
operators where being developed for D (and I'm not just talking about
this particular suggestion).  Parhaps the newsgroup archives deserve a
re-visit :d

-Anderson

i don't think you shoot down anything. except one: D has, after possibly long discussions, some way to overload operators.

 that you can use it, people start to realise that it behaves rather wrong.

 i'm rather new to D, so i wasn't around then. i would have cried right

 that this way will not be the way that makes them useful. operators

 about binary ones), act on two objects, with equal importance. there is no

 that can say wich one has to be the object that provides the operator.

 the operator has to be free of the objects. that way, operators can get

 bindings to all sort of type operations. just as its possible in c++. just

 gets most used in c++ actually. f.e. for streams. where you can add new

 the stream operator simply..

 T op (A a,B b) {
 return op_operation(a,b);
 }

 A a;
 B b;
 T t = a op b;

 that way, it would be VERY useful..

 vec3 + (vec3 a,vec3 b) {
 return vec3.add(a,b);
 }

 that style..

Nov 11 2003
parent reply davepermen <davepermen_member pathlink.com> writes:
I'm pretty sure that a search of the archives will reveal that the only
person who is happy with having binary operators as member functions is the
one who's writing the compiler. The rest of us are quite unhappy about it

the easiest would be to not write a compiler at all.. so, Walter, please think about operators as functions, not methods. this is rather important, you know?! if you know c++ then you know its uses, and you know as well that it gains oo logic, namely... you make the object more "closed".. i don't remember the correct namings.. i want 3 things. one (ONE) stream-operator, operator overloads as functions, and implicit instanciated templates. then, i'm done. :D
Nov 11 2003
parent reply "Achilleas Margaritis" <axilmar b-online.gr> writes:
"davepermen" <davepermen_member pathlink.com> wrote in message
news:bos3at$9qt$1 digitaldaemon.com...
I'm pretty sure that a search of the archives will reveal that the only
person who is happy with having binary operators as member functions is


one who's writing the compiler. The rest of us are quite unhappy about it

the easiest would be to not write a compiler at all.. so, Walter, please think about operators as functions, not methods. this

 rather important, you know?! if you know c++ then you know its uses, and

 know as well that it gains oo logic, namely... you make the object more
 "closed".. i don't remember the correct namings..

 i want 3 things. one (ONE) stream-operator, operator overloads as

 implicit instanciated templates.

 then, i'm done. :D

Yes!!! this is very important. Operators are just syntactic sugar. They should just be declared outside of classes!!!
Nov 12 2003
next sibling parent reply Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi> writes:
In article <bou4i2$hnl$1 digitaldaemon.com>, Achilleas Margaritis wrote:
 
 "davepermen" <davepermen_member pathlink.com> wrote in message
 news:bos3at$9qt$1 digitaldaemon.com...
I'm pretty sure that a search of the archives will reveal that the
only person who is happy with having binary operators as member
functions is the one who's writing the compiler. The rest of us are
quite unhappy about it

the easiest would be to not write a compiler at all.. so, Walter, please think about operators as functions, not methods. this is rather important, you know?! if you know c++ then you know its uses, and you know as well that it gains oo logic, namely... you make the object more "closed".. i don't remember the correct namings.. i want 3 things. one (ONE) stream-operator, operator overloads as functions, and implicit instanciated templates. then, i'm done. :D

Yes!!! this is very important. Operators are just syntactic sugar. They should just be declared outside of classes!!!

Indeed, I think operators and functions should have equal rights. 1 + 2 is just a little bit more readable way to say add(1, 2). If operators aren't allowed outside objects, then why does D allow freestanding functions, then? Maybe all functions should be member functions, like in Java. -A
Nov 13 2003
parent "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
 Maybe all functions should be member
 functions, like in Java.

That would save us all the trouble of learning D, and Walter the trouble of writing it. ;)
Nov 13 2003
prev sibling parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Achilleas Margaritis wrote:

 Yes!!! this is very important. Operators are just syntactic sugar. They
 should just be declared outside of classes!!!

This would work well with structs, but not with classes, because they would not inherit correctly. One could think of static member functions being searched in both classes participating in an operation, but this would violate the D overloading rule which only works within the same scope. -eye
Nov 14 2003
parent davepermen <davepermen_member pathlink.com> writes:
where are the problems?

if you want to have inheritation, make an operator-method, and overload the
operator then.. inherits great.

In article <bp2l79$1je7$1 digitaldaemon.com>, Ilya Minkov says...
Achilleas Margaritis wrote:

 Yes!!! this is very important. Operators are just syntactic sugar. They
 should just be declared outside of classes!!!

This would work well with structs, but not with classes, because they would not inherit correctly. One could think of static member functions being searched in both classes participating in an operation, but this would violate the D overloading rule which only works within the same scope. -eye

Nov 14 2003
prev sibling parent Matthias Becker <Matthias_member pathlink.com> writes:
It would also be very useful to be able to declare our own operators.
Operators are just syntactic sugar anyway. For example:

operator int x(int a, int b) {
    return a * b;
}

usage:

int b = 10 x 50;

And than you get expressions like: foo bar quer whatever dont_know_any_cool_names_any_more blablabla and_so_forth; And this is leagal code. (bar, whatever and blablabla are operators)
Nov 12 2003