dsimcha wrote:
> == Quote from Andrei Alexandrescu (SeeWebsiteForEmail@erdani.org)'s article
>> D has operator >>> which means "unsigned shift to the right", inherited
>> from Java. But it doesn't need it because D has unsigned types, which
>> can be used to effect unsigned shift. (Java, lacking unsigned types, had
>> no other way around but to define a new operator.)
>> Should we yank operator>>>?
>> Andrei
> 
> I've never used >>> before, so I'm not 100% sure I understand what it's supposed
> to do.  However, I wrote a test program to see if it does what I think, and if my
> understanding is correct, it's not even properly implemented.  The fact that
> noone's noticed until now is a pretty clear indication that noone uses >>> .

Not so. That must be a regression caused by bugzilla 3115. Ouch.

Andrei Alexandrescu wrote:
> D has operator >>> which means "unsigned shift to the right", inherited from Java. But it doesn't need it because D has unsigned types, which can be used to effect unsigned shift. (Java, lacking unsigned types, had no other way around but to define a new operator.)
> 
> Should we yank operator>>>?
> 
> 
> Andrei

Yes. It's an operation that doesn't make much sense -- it operates on raw bits, not on integers. It's tied to a twos-complement representation, and not to mathematics. If you ever try to implement >>> for bigints, you find out how wierd it is.
I guess in the Java case, x>>>1 is cast(int)((cast(uint)x)>>1)
and there's no other way of doing it in a language which had no unsigned types.
It had some merit before D had templates. Now, I don't think it has much use.

On Dec 7, 09 01:24, bearophile wrote:
> Andrei Alexandrescu:
>> Should we yank operator>>>?
>
> We can change it purpose and add the other one:
> <<<  rotate left
>>>> rotate right
>
> Bye,
> bearophile

No, it will _silently_ break code that uses >>> as unsigned right shift.

dsimcha wrote:
> == Quote from bearophile (bearophileHUGS@lycos.com)'s article
>> Andrei Alexandrescu:
>>> Should we yank operator>>>?
>> We can change it purpose and add the other one:
>> <<< rotate left
>>>>> rotate right
>> Bye,
>> bearophile
> 
> This is a good idea, although rotate may be seldom enough used not to warrant its
> own (possibly overloadable) operator.  std.intrinsic might be a better place for
> rotate.  On the other hand, rotate is a single ASM instruction, at least on x86.
> In a close to the metal language, there needs to be a straightforward, efficient
> way to access it.

I think DMD should just do what gcc does: recognize that
(x << 32-n | x>>n)  is ror n
(x << n | x>> 32-n) is rol n

where x is int. Ugly, but doesn't require an intrinsic.

== Quote from KennyTM~ (kennytm@gmail.com)'s article
> On Dec 7, 09 01:24, bearophile wrote:
> > Andrei Alexandrescu:
> >> Should we yank operator>>>?
> >
> > We can change it purpose and add the other one:
> > <<<  rotate left
> >>>> rotate right
> >
> > Bye,
> > bearophile
> 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.

On Dec 7, 09 03:41, Don wrote:
> dsimcha wrote:
>> == Quote from bearophile (bearophileHUGS@lycos.com)'s article
>>> Andrei Alexandrescu:
>>>> Should we yank operator>>>?
>>> We can change it purpose and add the other one:
>>> <<< rotate left
>>>>>> rotate right
>>> Bye,
>>> bearophile
>>
>> This is a good idea, although rotate may be seldom enough used not to
>> warrant its
>> own (possibly overloadable) operator. std.intrinsic might be a better
>> place for
>> rotate. On the other hand, rotate is a single ASM instruction, at
>> least on x86.
>> In a close to the metal language, there needs to be a straightforward,
>> efficient
>> way to access it.
>
> I think DMD should just do what gcc does: recognize that
> (x << 32-n | x>>n) is ror n
> (x << n | x>> 32-n) is rol n
>
> where x is int. Ugly, but doesn't require an intrinsic.
>

It's still better to provide a std.???.rol(T)(T x) and ror because that (least) ugly code only works if you already know x is a uint. That ror code won't work if x is signed (int: cast into uint first) or is 64-bit (ulong: replace 32 with (8*x.sizeof)).

On Sun, 06 Dec 2009 23:00:42 +0300, dsimcha <dsimcha@yahoo.com> wrote:

> == Quote from KennyTM~ (kennytm@gmail.com)'s article
>> On Dec 7, 09 01:24, bearophile wrote:
>> > Andrei Alexandrescu:
>> >> Should we yank operator>>>?
>> >
>> > We can change it purpose and add the other one:
>> > <<<  rotate left
>> >>>> rotate right
>> >
>> > Bye,
>> > bearophile
>> 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.

Why not just make an instrinsic function for that? Is it *really* used that often to deserve a unique identifier?

Andrei Alexandrescu wrote:
> D has operator >>> which means "unsigned shift to the right", inherited from Java. But it doesn't need it because D has unsigned types, which can be used to effect unsigned shift. (Java, lacking unsigned types, had no other way around but to define a new operator.)

It's there because in C/C++ one often winds up writing:

   (unsigned)x >> i;

to ensure that one gets an unsigned right shift. The problem is that the cast can have many other side effects if x is not of type int. For example, if x is a struct with an overloaded cast operator. Or if x is a long and you just lost half your value.

> Should we yank operator>>>?

No.

Don wrote:
> It's tied to a twos-complement representation, and not to mathematics.

That's true, and D explicitly is tied to twos-complement integers.

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.

Only works so well.

This would still remain a problem for porting other languages to D. Java code would silently break as it is ported, for example.  If you're porting you need to know these things anyways, but it doesn't help.

It doesn't seem justified to add such a problem just to get convenient notation for bit rotation.

FWIW, I'd be perfectly happy with >>> just being removed.