I see in Extended C :http://web.ss.pub.ro/~vycxs/ecdk/ecl_x.htm
has an exchange operator which very , very notable :
x=0;
y=3;
Just write :
x<->y so x=3;y=0;
Whether D can make a builtin exchange operator like that , and a optExchange
for exchange operator overloading ?

"Tu Nam" <dreamweaver@mail15.com> wrote in message news:c7mtv3$10p4$1@digitaldaemon.com...
> I see in Extended C :http://web.ss.pub.ro/~vycxs/ecdk/ecl_x.htm
> has an exchange operator which very , very notable :
> x=0;
> y=3;
> Just write :
> x<->y so x=3;y=0;
> Whether D can make a builtin exchange operator like that , and a
optExchange
> for exchange operator overloading ?

This comes up now and then, and it's a seductive idea. But there just doesn't seem to be enough utility in it to justify making it an operator.

I'd very much like this, but only if opSwap was available for UDTs

"Tu Nam" <dreamweaver@mail15.com> wrote in message news:c7mtv3$10p4$1@digitaldaemon.com...
> I see in Extended C :http://web.ss.pub.ro/~vycxs/ecdk/ecl_x.htm
> has an exchange operator which very , very notable :
> x=0;
> y=3;
> Just write :
> x<->y so x=3;y=0;
> Whether D can make a builtin exchange operator like that , and a optExchange
> for exchange operator overloading ?
>
>

Well , the first use I just thought is in sorting algorithms.
That operator is more be useful in sort .
"Walter" <newshound@digitalmars.com> wrote in message
news:c7muj8$11je$1@digitaldaemon.com...
>
> "Tu Nam" <dreamweaver@mail15.com> wrote in message news:c7mtv3$10p4$1@digitaldaemon.com...
> > I see in Extended C :http://web.ss.pub.ro/~vycxs/ecdk/ecl_x.htm
> > has an exchange operator which very , very notable :
> > x=0;
> > y=3;
> > Just write :
> > x<->y so x=3;y=0;
> > Whether D can make a builtin exchange operator like that , and a
> optExchange
> > for exchange operator overloading ?
>
> This comes up now and then, and it's a seductive idea. But there just doesn't seem to be enough utility in it to justify making it an operator.
>
>

How about a function tenplate in a coming up standard template library?

-eye

Tu Nam schrieb:

> Well , the first use I just thought is in sorting algorithms.
> That operator is more be useful in sort .

Yes, I've added one in DTL. But because templates are not implicitly instantiated, it's a fair amount of eye candy.

"Ilya Minkov" <minkov@cs.tum.edu> wrote in message news:c7oho2$fnn$2@digitaldaemon.com...
> How about a function tenplate in a coming up standard template library?
>
> -eye
>
> Tu Nam schrieb:
>
> > Well , the first use I just thought is in sorting algorithms. That operator is more be useful in sort .

Tu Nam wrote:
> I see in Extended C :http://web.ss.pub.ro/~vycxs/ecdk/ecl_x.htm
> has an exchange operator which very , very notable :
> x=0;
> y=3;
> Just write :
> x<->y so x=3;y=0;
> Whether D can make a builtin exchange operator like that , and a optExchange
> for exchange operator overloading ?
> 
> 

I like the idea... it should be possible to optimise for lots of types too.

Just to keep the conversation going, how about:
x<=>y

or
x:=:y

or

x:-:y

or

x<~>y


-- 
Alex

> Tu Nam wrote:
> > I see in Extended C :http://web.ss.pub.ro/~vycxs/ecdk/ecl_x.htm
> > has an exchange operator which very , very notable :
> > x=0;
> > y=3;
> > Just write :
> > x<->y so x=3;y=0;
> > Whether D can make a builtin exchange operator like that , and a optExchange
> > for exchange operator overloading ?
> >
> >
>
> I like the idea... it should be possible to optimise for lots of types too.
>
> Just to keep the conversation going, how about:
> x<=>y

That's already an operator (comparison) in Ruby. To overload that would be
confusing.

> or
> x:=:y
>
> or
>
> x:-:y
>
> or
>
> x<~>y

None of them are as clear, to me at least, as <->

<snip>
>> > I see in Extended C :http://web.ss.pub.ro/~vycxs/ecdk/ecl_x.htm
>> > has an exchange operator which very , very notable :
>> > x=0;
>> > y=3;
>> > Just write :
>> > x<->y so x=3;y=0;
>> > Whether D can make a builtin exchange operator like that , and a optExchange
>> > for exchange operator overloading ?
</snip>

I dunno... of course I'm against any new operators anyway, but this in particular may cause trouble, methinks.

I expect it would be fine for ints and such, but for instances of objects I would expect it to simply exchange the values of the references, not the contents (certainly much faster). But this is where the trouble would come in, what if I have an array of MyObjs that I want to sort (with a bubble sort for instance) and use two references: Ofront and Oback, when I use:

Ofront <-> OBack

to exchange them it would have no effect on the array. So newbies would have to be trained to use indices rather than references to array members:

MyArray [ ifront ] <-> MyArray [ iback ]

which is not as clear, but better than not having the exchange operator. Certainly it has some value, but also causes potential for trouble.

Anyway... mightn't it be better to leave well enough alone and not cause the same kind of confusion that that D strings cause with printf() ?

Juan C wrote:

> I dunno... of course I'm against any new operators anyway,

I agree in so far, that new operators should be consider with special care. They should be descriptive, and they should not be used where similar actions might be mixed up. They should not be overloaded with different meaning in different context. Apart from that, I really have no problems with new operators. The fact that I have to learn something new does not mean that it is bad.

> I expect it would be fine for ints and such, but for instances of objects I would expect it to simply exchange the values of the references, not the contents (certainly much faster). But this is where the trouble would come in, what if I have an array of MyObjs that I want to sort (with a bubble sort for instance) and use two references: Ofront and Oback, when I use:
> 
> Ofront <-> OBack
> 
> to exchange them it would have no effect on the array. So newbies would have to be trained to use indices rather than references to array members:
> 
> MyArray [ ifront ] <-> MyArray [ iback ]
> 
> which is not as clear, but better than not having the exchange operator. Certainly it has some value, but also causes potential for trouble.

I don't think that confusion would be worse than for the = operator.