Walter Bright wrote:
Andrei Alexandrescu wrote:
Note that your argument is predicated on using signed types instead of
unsigned types in the first place, and tacitly assumes the issue is
frequent enough to *add a new operator*. Yet unsigned shifts correlate
naturally with unsigned numbers.
So what is exactly that is valuable in >>> that makes its presence in
the language justifiable?
Generally the irritation I feel whenever I right shift and have to go
back through and either check the type or just cast it to unsigned to be
sure there is no latent bug.
But x >>> 1 doesn't work for shorts and bytes.
For example, the optlink asm code does quite a lot of unsigned right
shifts. I have to be very careful about the typing to ensure a matching
unsigned shift, since I have little idea what the range of values the
variable can have.
I've read the OMF spec, and I know it includes shorts and bytes.
So I really don't think >>> solves even this use case.
