shr naming consistency resolution

[capocasa]

shr performs an arithmetic right shift on signed integers, and a logical right shift on unsigned integers.

(1) While the documentation is clear for signed integers, the behavior for unsigned integers isn't specified. This would be easy enough to fix in documentation.

(2) ashr makes sense in this context, as it is an explicit arithmetic right shift, supported only on signed integers. It's weird that it can't be called as an operator.

(3) It would be really cheap to add an lshr operator that only applies to unsigned integers for consistency.

(4) Of course it would be nice for ashr to also support signed integers, and the proposed lshr to also support signed integers

Not saying anything yet about who would shoulder the implementation burden, I just wanted to check if there is agreement on the status and what would be desirable and/ or easy.

Note: previous version removed, as it was based on incorrect understanding.

[RSDuck]

I agree with the documentation part, but I don't think separating them into different operators makes sense:

Differentiating based on the sign of the operation is also used in other places in Nim e.g. for division (4 div -2 != uint(4) div uint(-2). Should we separate those into sdiv and udiv?

Also while shifting right signed values which are negative is undefined behaviour in C using arithmetic right shift then is the defacto standard.

[capocasa]

I see, I didn't know that.

Sure, we wouldn't want 100 new ops and casting before shifting (or chosing your type differently) is easy enough.

In this light, ashr seems like cruft. Should it be deprecated?