On Mon, 07 Dec 2009 02:11:16 +0100, Jerry Quinn <jlquinn@optonline.net> wrote:

> Walter Bright Wrote:
>
>> dsimcha wrote:
>> > == Quote from KennyTM~ (kennytm@gmail.com)'s article
>> >> No, it will _silently_ break code that uses >>> as unsigned right  
>> shift.
>> >
>> > Well, we could get around this by making >>> an error for a few  
>> releases, and then
>> > only after everyone's removed their >>>s that mean unsigned shift, we  
>> could drop
>> > in the rotate semantics.
>>
>> It'll still silently break code moving from D1 to D2.
>
> Well, I could see the value of poviding a rotate operator.
>
> Since >>> is tainted, what about >>@ and <<@ for integral rotation?
>
> Jerry
>

I was thinking <<> and <>>. They represent the fact that some bits end up
on the wrong side. Still, I don't think there're enough use cases for an
operator.

-- 
Simen

Simen kjaeraas Wrote:

> On Mon, 07 Dec 2009 02:11:16 +0100, Jerry Quinn <jlquinn@optonline.net> wrote:
> > Well, I could see the value of poviding a rotate operator.
> >
> > Since >>> is tainted, what about >>@ and <<@ for integral rotation?
> 
> I was thinking <<> and <>>. They represent the fact that some bits end up on the wrong side. Still, I don't think there're enough use cases for an operator.

I'd argue against <<> and <>> since they'd be very easy to misread and mistype.  I can believe that an operator isn't necessary, but there should definitely be a standard way for folks to end up with single-asm instructions for rotation without resorting to ugliness.  Consider PowerPC that has a whole collection of powerful rotation instructions.

Sun, 06 Dec 2009 12:24:33 -0500, bearophile wrote:

> Andrei Alexandrescu:
>> Should we yank operator>>>?
> 
> We can change it purpose and add the other one: <<< rotate left
>>>> rotate right

Or some other user cases

a >>> 1 // count the number of leading 1s
a <<< 0 // count the number of trailing zeros

Those are also single instructions on some architectures. :)