Right now, it’s quite messy and irritating to create numeric values that employ the use of the bit32 library’s shifting capabilities for simple value storage. Contrary to previous requests, this is not for the capability (which was addressed with the formal implementation of bit32), but rather for the syntax.
Many times, my implementations using bit shifts occur in custom enums that I design. I would like to be able to write my definitions like this:
However, Luau does not offer shl/shr operators (<<, >>) in its syntax. This means that I have to either use,
bit32.shiftl(1, n), which feels unconventional for defining what is, for all intents and purposes, a constant value.
Binary definition (0b0001), which can get hard to read very quickly, even if using separators (_) for every nibble or byte.
Flat out remembering powers of 2 (1, 2, 4, 8, 16, …), which gets hard to read past the values most people know; it’s hard for people who don’t deal with binary often to look at a number like 131072 and instantly know that it’s bit 17.
While all methods are functional, they all have some associated cost with code cleanliness. This is my primary concern.
I actually ran into this issue yesterday where I needed something like this but, it had nothing to do with this platform and everything to do with pure Lua. I am used to being able to use << & >> in C or C++ and having this functionality in the form of bit32.shiftl(1, n) & related is weird. Seen as Luau is supposed to be this cool thing where you can do cool stuff, this would make a great addition. However, it does feel like a bit of an edge case. I don’t really see many people using this on this platform so, from a PM standpoint I feel like the priority if any, would be low. I still very much agree with this and I do think, for what it’s worth, it should be added.
If these bitwise operators were added, would the other bitwise operators be added (bitwise and &,bitwise or |, bitwise xor ~, bitwise not unary ~)? Would these operators support metamethods?
Lua 5.3 added bitwise operators, probably because of the addition of an integer type. Lua 5.3+ by default uses 64 bit integers by default, so it would probably be confusing if these used 32 bit integers (although Lua 5.3+ can be compiled with a smaller integer type so it wouldn’t be that bad).
What about hexadecimal? (if hex floats were supported (like how tonumber supports hex floats) this could be even easier, e.g. 0x1p0, 0x1p1, and 0x1p2)
local FLAG_A = 0x1
local FLAG_B = 0x2
local FLAG_C = 0x4
-- and so on
Alternatively, a function could be used.
local function FLAG(N)
return bit32.lshift(1,N-1) -- lshift, not shiftl
end
local FLAG_A = FLAG(1)
local FLAG_B = FLAG(2)
local FLAG_C = FLAG(3)
-- and so on
Adding many new operators also has a cost, namely there will have to be many new VM instructions to accommodate the new operators (which could be a problem).
Speaking of which I believe this is definitely possible considering that the syntax has already been modified to add support for & and | in the context of creating Luau types and type unions, and function templates are apparently soon to come as well, so I agree with this suggestion.
Also, yes and while it would also add more metatable methods (such as metatable.__shiftl and metatable.__band) i feel like it would be a great addition regardless, and also i would support if .__and and .__or and .__not could be given some love while they’re at it.
Lua 5.3+ uses __shl and __shr, not __shiftl. If bitwise operators are going to be adopted, then they should be consistent with Lua 5.3+ to avoid confusion.