Adding these common operators to Lua would make my fiddly math code easier to read.
Having to type “nw = nw + 1” or “dx = dx * f” seems pedantic.
111 Likes
and >>=, <<=, ^=, |=, &=, ~= operators.
There’s a reason why Python 2 added this feature.
1 Like
I was surprised a couple weeks ago to find out that Roblox does support the Bitop operators, which gets you most of the way there on a lot of those.
13 Likes
It doesn’t really make sense to have -- be an operator, given that’s how you declare a comment.
10 Likes
Yeah that is a little yuck.
Guess we should just ditch Lua and use C# instead.
Joking aside, I think I probably use ++ ten times more often than - -.
++, +=, and *= are the most useful I think.
16 Likes
Related topic:
5 Likes
++ only makes sense on ints, so maybe this feature is tied up with adding types to the language.
If I had to guess, that’s probably why they aren’t supported in vanilla Lua.
5 Likes
Lua 5.3 has integers (before you ask, the semantics involving them are horrible so you don’t want them in Roblox) and there’s no increment or decrement operators, so it can’t be the lack of integers. I imagine the reason is simplicity; part of Lua’s design philosophy is to be as simple as possible, for better or for worse.
A minor correction here is that it has the bit32 library from Lua 5.2, not LuaJIT’s bit library.
1 Like
To prevent inconsistencies I think we should just stick with adding the the op= form such as += and -=.
++ is just shorthand for +=1, which is just one or two extra characters every time whilst also being more
explicit and consistent (as -- is not valid in Lua, but we are able to sidestep that issue entirely here).
An extra character or two doesn’t really matter in comparison to the current issue, which is mostly that we need to write variable names twice.
I’m generally in opposition of ++ and -- because they don’t provide that much benefit and introduce one-off syntax to the language which is kinda stupid imo.
Also, about the simplicity argument: op= form could literally just be syntax sugar in terms of the way it is implemented. I don’t really see any significant downsides, and op= form is itself fairly simple and intuitive.
19 Likes
I don’t personally feel that borrowing operators from other languages for the sake of typing a couple fewer characters–with no performance benefit–is worth making Roblox Lua source more incompatible with standard Lua. New developers trying to learn to code on this platform would inevitably encounter these and not find them in any Lua reference. If you’re going to go off the standard, I think there should be real runtime wins to justify it.
2 Likes
Yeah, I’m not trying to make the argument that it’s what we should actually do it, I’m just trying to say that if we do, that would probably be the best way to go about it. I should have mentioned that in my post.
I agree that it should be done on actual Lua, if it gets done at all. But it should also be noted that we already have the new type checking system which breaks compatibly completely (although it is less obscure to get information about than special operators would be).
1 Like
These operators are standard if you already know how to program in another language and you come to Roblox and try to make games on Roblox. For instance, if you know Javascript, C, Java, or Python you might be used to writing “+=”.
Developers new to programming don’t need to use them.
3 Likes
Yeah, but they’re standard in that they are part of other languages that all have their own standards. You can make this argument for other things I wish Lua had, like the continue keyword. So, I guess it’s not adding these to Roblox scripting that I object to, it’s doing so while continuing to call Roblox script “Lua”. If static typing is going to be a thing, maybe it’s time to branch off and formally define Roblox Script as a distinct language, with Lua ancestry?
I can neither confirm nor deny that we thought about this before. I also wouldn’t know whether we wrote something about it in a release note next week.
57 Likes
What did you do about - -? Prefix operator instead?
7 Likes
Both – and ++ make me unhappy. Python got it right when it decided to require all assignment occur with an =. Instead of ++, += 1 removes all ambiguity in how an interpreter will interpret the addition. Technically ++ operations in many cases in C are undefined.
I guess we’ll see what Roblox does.
9 Likes
At least in C it makes sense because some processors have an assembly instruction for increment by 1 and on some architectures ++ is the only atomic operation.
Although now most modern compilers are probably good enough to figure out when x += y really means x++ and most modern CPUs probably don’t care.
4 Likes
Do the new operators have metamethods or do they use the old ones?
I agree–Rust did the same thing–only having += and -=. ++ and -- also return values that are confusing to a lot of people, and leads to a lot of mistakes.
Why doesn’t Rust have increment and decrement operators?
Preincrement and postincrement (and the decrement equivalents), while convenient, are also fairly complex. They require knowledge of evaluation order, and often lead to subtle bugs and undefined behavior in C and C++.
x = x + 1orx += 1is only slightly longer, but unambiguous.
3 Likes
If you write code that requires a reader to know evaluation order to understand it, you are a bad programmer. Parens are free.
Also if you write code that requires a return value from x++ (y = x++), you are a bad programmer.
But don’t take my x++;
My 2c.
2 Likes