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.


that way,

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


operator(), 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


will

 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.


 that way,

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


 operator(), 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


 will

 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.
      


that way,
    


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


operator(), 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
      


will
    


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


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




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


Hhaha.

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