-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Proposal]: Unsigned right shift operator #4682
Comments
Is it common enough to need an operator? Couldn't it just be an ordinary static method? |
Roslyn recognizes |
Also, if we really wanted to use that syntax as an operator, we'd use it. That's just roslyn trying to be helpful, nothing in the C# spec mandates that the compiler produce a good error when encountering merge conflict markers :). |
Also nothing mandates that conflict markers be composed only of |
Note: Spec is here |
Unsigned right shift operator
Speclet: https://github.com/dotnet/csharplang/blob/main/proposals/csharp-11.0/unsigned-right-shift-operator.md
Summary
An unsigned right shift operator will be supported by C# as a built-in operator (for primitive integral types) and as a user-defined operator.
Motivation
When working with signed integral value, it is not uncommon that you need to shift bits right without replicating the high order bit on each shift. While this can be achieved for primitive integral types with a regular shift operator, a cast to an unsigned type before the shift operation and a cast back after it is required. Within the context of the generic math interfaces the libraries are planning to expose, this is potentially more problematic as the type might not necessary have an unsigned counterpart defined or known upfront by the generic math code, yet an algorithm might rely on ability to perform an unsigned right shift operation.
Detailed design
There are some considerations around what the operator could be and the initial suggestion is
>>>
, to match other languages. It is suggested that>>>
be explicitly an unsigned right shift and>>
would continue being just “right shift” with no strict definition. For primitive unsigned integral types>>>
will be allowed, but will be equivalent to>>
.Drawbacks
Alternatives
Unresolved questions
Design meetings
The text was updated successfully, but these errors were encountered: