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/

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

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

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

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

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

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

>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

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

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