Skip to content

Proposal: Circular shift operator #7183

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

Open
mrakh opened this issue Nov 20, 2020 · 9 comments
Open

Proposal: Circular shift operator #7183

mrakh opened this issue Nov 20, 2020 · 9 comments
Labels
proposal This issue suggests modifications. If it also has the "accepted" label then it is planned.
Milestone

Comments

@mrakh
Copy link
Contributor

mrakh commented Nov 20, 2020

Circular shift (or bit rotation) is a common operation to perform and most every architecture out there has hardware support for it. Since we already use the % token to qualify existing operators with wraparound behavior, I propose we use >>%/>>%=/<<%/<<%= to denote circular shift operations.

@SpexGuy
Copy link
Contributor

SpexGuy commented Nov 20, 2020

I think the standard meaning of % elsewhere in the language (discard overflow) is kind of the opposite of this use. Other than that though I think this is worth doing. Maybe as a builtin instead?

@mrakh
Copy link
Contributor Author

mrakh commented Nov 20, 2020

I think the standard meaning of % elsewhere in the language (discard overflow) is kind of the opposite of this use. Other than that though I think this is worth doing. Maybe as a builtin instead?

For addition, subtraction and multiplication with %, there is no distinction between wraparound vs. overflow/underflow, since the operations are performed modulo a power of two. The % token is described as having wrapping behavior in the docs, so that's what I went with. But if the operator is too obscure, I suppose a built-in would serve just as well.

@LemonBoy
Copy link
Contributor

math.rotl is only one import away, theres no need to have a thousand builtin functions for every operation.

@alexnask alexnask added the proposal This issue suggests modifications. If it also has the "accepted" label then it is planned. label Nov 22, 2020
@Vexu Vexu added this to the 0.8.0 milestone Nov 27, 2020
@andrewrk andrewrk modified the milestones: 0.8.0, 0.9.0 May 19, 2021
@andrewrk andrewrk modified the milestones: 0.9.0, 0.10.0 Nov 23, 2021
@andrewrk andrewrk modified the milestones: 0.10.0, 0.11.0 Apr 16, 2022
@The-Futurist
Copy link

The-Futurist commented Jan 16, 2023

@mrakh
I'm wondering about this myself, for a different language though.

These have come up as options:

rotate right: @>
rotate left: <@

One can devise variants of these too.

rotate right: >@>
rorate left: <@<

Not sure about Zig, in my case @ is able to be used in a token like this.

@andrewrk andrewrk modified the milestones: 0.11.0, 0.12.0 Apr 9, 2023
@andrewrk andrewrk modified the milestones: 0.13.0, 0.12.0 Jul 9, 2023
@lunacookies
Copy link

An option I like is <<< and >>> from Jai. I see the point about just using a library function for this, though.

@rohlem
Copy link
Contributor

rohlem commented Sep 18, 2023

No opinion about this, just wanted to note that in Java >> sign-extends while >>> shifts in 0s.
I generally agree we don't need operators (nor builtins) for everything, though I don't know how to justify what to include and what not to.

@farteryhr
Copy link

farteryhr commented Oct 7, 2023

i think we're safe to have >>>> <<<< for being infrequently used, cheap, and cool.
also see #5220 like proposals.

@Validark
Copy link
Contributor

No opinion about this, just wanted to note that in Java >> sign-extends while >>> shifts in 0s. I generally agree we don't need operators (nor builtins) for everything, though I don't know how to justify what to include and what not to.

In my opinion, what we include as fundamental operators affects how people think about and approach problems. If not given an operator, it has more friction to use it, and fewer people will know about it, even though it's a 1 cycle operation on pretty much all hardware, a fact that I think most programmers just forget about since it is not an operator.

I personally think an operator, not a builtin, is the appropriate level of at-your-fingertips Zig should provide for such a simple, low-level, and widely supported operation.

<<< and >>> are my preferences. Yes, a Java or JavaScript person might need to learn that these are rotate operators, but that's fine, they can learn that.

@Khitiara
Copy link

Im more in favor of the >>%, <<% version personally, given the wrapping idea common to %-based operators for arithmetic

@andrewrk andrewrk modified the milestones: 0.14.0, 0.15.0 Feb 9, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
proposal This issue suggests modifications. If it also has the "accepted" label then it is planned.
Projects
None yet
Development

No branches or pull requests