http://dlang.org/expression.html#ShiftExpression claims:
"<< is a left shift. >> is a signed right shift. >>> is an unsigned right shift."
This is false. '>>' is an unsigned right shift for unsigned types.
Comment #1 by clugdbug — 2012-05-02T08:32:33Z
I guess you mean it makes you think that x >> 1 is
(cast(signed!(typeof(x)))x) >> 1
and that x >>> 1 is
(cast(unsigned!(typeof(x)))x) >> 1
?
Both of which are untrue.
Comment #2 by timon.gehr — 2012-05-02T10:46:16Z
(In reply to comment #1)
> I guess you mean it makes you think that x >> 1 is
>
> (cast(signed!(typeof(x)))x) >> 1
>
Yes, as it is phrased, -1U >> 1 == -1U would have to hold. The bug report is about this.
> and that x >>> 1 is
>
> (cast(unsigned!(typeof(x)))x) >> 1
>
> ?
>
> Both of which are untrue.
We should fix >>> or get rid of it.
The usual integral promotion rules are an extremely bad fit here.
Comment #3 by bugzilla — 2019-12-23T11:11:40Z
IMHO the documentation is quite clear here and correct.
First, according to the docs, the opperands have to undergo integer promotion. But for ulong, there is not promotion, therefore the opperand stays ulong.
It also tells, that the result is of the same type as the left side, hence the result is an ulong. And therefore there are no signs. I read ">> is a signed right shift" as "if there is a sign, it will be preserved". That's true here.
Comment #4 by timon.gehr — 2019-12-23T11:55:05Z
Please stop closing issues just for the sake of it. It's clearly not true that `>>` is a signed right shift.
Comment #5 by bugzilla — 2019-12-23T12:31:48Z
(In reply to timon.gehr from comment #4)
> Please stop closing issues just for the sake of it.
I do not close issues "just for the sake of it". I closed this one, because I think it's invalid. And I wrote, why I think so. And as Don has IMHO expressed that opinion too, there is some justification in doing so. And in doing so I'll give the next one, who is closing this as invalid even more justification.
> It's clearly not true that `>>` is a signed right shift.
If it were so "clearly not true", as you state, I should see this too. But I can't, so your statement is wrong.
Comment #6 by timon.gehr — 2019-12-23T13:15:21Z
(In reply to berni44 from comment #5)
> ...
> If it were so "clearly not true", as you state, I should see this too. But I
> can't, so your statement is wrong.
https://en.wikipedia.org/wiki/Arithmetic_shift
"In computer programming, an arithmetic shift is a shift operator, sometimes termed a signed shift (though it is not restricted to signed operands)."
Comment #7 by timon.gehr — 2019-12-23T13:17:34Z
(In reply to berni44 from comment #5)
> ... And as Don has IMHO
> expressed that opinion too, there is some justification in doing so.
Don merely clarified what the issue is.
Comment #8 by robert.schadek — 2024-12-15T15:21:55Z