> Because we can then deprecate ashr.
@Araq, it would be great to get rid of that!
However, as per the latest documentation for shr:
> ...filling vacant bit positions with the sign bit.
This would mean that a shr of a "minus one" of any type should do the same as a
no-op whereas a shr of any u
Because we can then deprecate `ashr`.
now I am completely confused. When there is a `ashr` (which I have never
noticed), why is there the need to change the behavior of `shr` for signed
`int`? I can't see the point.
We already have `ashr`. We considered adding `ushr` for the old "unsigned shr"
but then you might as well cast the numbers to unsigned before the `shr`
operation so it wouldn't gain us much.
I agree that `shr` on signed `int` is error prone, but that is how the things
are now. To have a save transition I would suggest to have 2 operators `shr`
and another one `ashr` or `sar` or whatever with signed shift behavior. We
should then deprecate `shr` for signed `int` and in the future mak
Compile with old code with `-d:nimOldShiftRight` to find all usages of `shr`.
Maybe we need a better transition period or a better solution altogether. I'm
open to suggestions. However, the old unsigned shr behaviour for signed numbers
also was seen as very error prone.
Yes, there is indeed a change in the documentation between 0.19.6 and 0.19.9.
Personally, for signed integers I would find more consistent to use an
arithmetic shift to the right. With a logical shift, _-2 shr 1_ is equal to
9223372036854775807 on a 64 bits machine which may seem odd. We would r
> I have not been able to reproduce
Well, it is very confusing. I looked in 019.9 docs this morning, and indeed it
was said that shr behaves as ashr. But example was stlll like shr, and
additional a separate ashr was mentioned. So maybe just a bug in docs.
Otherwise for sure adrianv would be ri
I have not been able to reproduce this behavior. On my Manjaro Linux with the
last development version (built with _choosenim_ ) _shr_ is a logical right
shift, not an arithmetic one. This is also the case with the last stable
version.
And there is already an arithmetic right shift in the syste
I don't know if I am overreacting, but just realized that
Run
has changed its meaning from unsigned shit to sign preserving shift. IMHO this
breaks a lot of code in a very dangerous way. A more thoughtful solution would
have been to introduce a sign preserving operator
10 matches
Mail list logo
