It would be nice if Roblox’s Luau had syntax sugar to allow us to write != instead of ~=. I’m not asking to remove ~=, it’d just change != to ~= in the backend so we have the option to use either. Literally every other programming language (JavaScript, Python, C++, Java, even SQL) uses != for the “not equal to” operator.
If Roblox is able to address this issue, it would improve my development experience because the “not equal to” operator would make sense and conform to standards.
Garry’s Mod Lua added C-like operators and to this day its almost universally considered to have been a huge mistake. It just breaks compatibility for all tooling without any real benefits, considering different languages already disagree on symbols for different operations. Also, having multiple ways to do the same thing only causes arguments.
I’m not asking to remove ~=, I’m asking to allow != in place of ~=, so I don’t see how this would break anything. People using custom-made syntax highlighters and such already have to deal with Luau’s new features, and they can always opt to not use !=. Plus, Luau already has multiple ways of doing things that aren’t present in traditional Lua, so people are going to argue regardless.
Switching to standards is great and all, but having two operators doing the exact same thing is going to be confusing. There is no other reason why this already widely used operator should be replaced in lua. It’s a language niche and it’s not confusing at all with general usage.
So it’s ok to have not (conditionA == conditionB) and conditionA ~= conditionB, but it’d be confusing to also have conditionA != conditionB, even though ~= literally means “about equal to”?
Maybe because I’ve been writing more C++ & JS recently, sometimes I write != in Lua by mistake and have to correct myself, so I thought “It’d be nice if Luau accepted either.” I didn’t expect so many people to be against this suggestion. I guess everyone’s entitled to their own opinion, and according to this small sample size, it seems my opinion is different from the norm. ¯\_(ツ)_/¯
I would agree if and only if this operator was present at the start. Given that it’s not, it does feel like it would be confusing to have two operators doing the exact same thing. Convenience thing as it may be for programmers that come from other languages, it just… doesn’t seem right to add now.
Although the symbol “~=” (I’m more used to writing it the other way which is the one symbol, a wavy equals) does indeed mean approximately equal to, we don’t have the capability to check approximate equals in Lua, so that argument doesn’t really hold water - it’s a linguistic thing, it only makes sense in discussion but not so much for the many years Lua has been using ~= to represent not equals.
Granted that there is already Roblox-specific API in the language that replaces default Lua API such as typeof() replacing rype(), this would be a welcome addition and would make it easier for new developers coming in from different languages and environments. The “~=” has been considered an oddity already, so why not make it easier for everyone by adding the “!=” that most programmers are already using?
You guys really wanna side with MATLAB? (matlab was created even before Lua, in the 1970s/1980s)
One thing I admire about Lua is how much it looks like psudo code. The “~=” kinda ruins it IMO. Welp, everyone’s entitled to their own opinion, and this would’ve been a low-priority update anyway.
Roblox’s Lua IDE specifically points out to use ~= when a user types in != to avoid confusion and to get users more used to Lua in general.
In my opinion, ~= is just one of the things that makes Lua different from all the other languages. I believe that Luau is currently easing towards being like other languages (being it’s other features inspired from said languages). As much as I don’t like ~= as an operator, I don’t think we should have variations of a singular operator. That kind of confuses syntax, wouldn’t you think?
I believe that the operator is fine as is right now. It’s not like someone can accidentally type the operator, because Roblox redirects to the proper operator.
I dont like changing semantics of languages, its just a really janky decision to change a semantic just for consistency with other languages, especially when Luau tries to be backwards compatible with most Lua code
To be fair, Luau can already parse != as “neq” stated by the warning it shows, but its a bit pointless for me
Well, I don’t think it’s fair to compare putting local everywhere to C++ and Java because they are both type-strict and require you to type the specific type you want before the variable name instead. You have to do this each time you define (or declare) a new variable, much like Lua(u).
The type-assuming equivalents to local would be var and auto for Java 10* and C++ respectively.
You didn’t mention Python so you didn’t tell anything wrong, but to be fair, Python is the same as Lua in this boat. Same for or and and. Why aren’t thise mentioned too if Python is not counted?
* versions before it didn’t support this at all. No this is not a mistake, I am talking about the real Java and not JavaScript. The JavaScript equivalent would be let
This is a slippery slope fallacy. I’m not asking Roblox to completely replace Lua. The main difference between all the things you listed and the “not equal to” operator is mathematical-correctness.
I don’t see why people would be upset with adding support for != if it remained backwards compatible. Luau already introduces a bunch of new operators, like a += 1 instead of a = a + 1. I don’t see how this is any different.
I’m on board for the != part because it’s been used for decades. I don’t mind the ~= since I switch my mindset to “Roblox programming” when I do it, but the easiest solution for all of us would be to allow some custom syntax options so that can just can add != is the same as ~= in studio and be done with it. There would be no need to argue about “should it be != or ~= or both” when it would be up to the developer to decide. When everything gets compiled down to binary, it makes no difference what “language” we humans use anyway.
Just because these programming languages uses the != notation (perhaps it was derived from C even if these programming languages don’t use braces for control blocks) for not equals operation does not mean all other programming languages uses !=.
Perhaps you only selected programming languages with the not equal operator being != as an example (confirmation bias(?))?
Should the not equal operator also be allowed to be written as /= and <>?
I could rephrase this section of argument to argue that /= could also be a syntax sugar to ~=:
…or I could change programming languages comparison of the notation of the not equals operator to create the illusion of JavaScript being the outlier here.
What standards? In terms of C-like syntax standard? I did not know there was a standard of notation for the not equals operator.
I would say get used to the not equals sign being ~= (for now if Roblox somehow did make != a syntax sugar at some point). Not every programming languages has to follow the convention of these certain programming language families you listed. Not saying that I agree or disagree with this request.
That’s a false analogy. Those languages are arbitrary, whereas and the ones I listed are some of the most popular programming languages in the world. Most popular programming languages use !=.
(here’s an article from berkeley.edu if you don’t believe me)
Either way, seems like Roblox is better off not adding this, as it seems like it’d piss off a lot of people (cough cough @ roblox staff who might agree w/ me, do it anyway press the button do it you know you want to)
That is why I didn’t mention it in the list of languages. The point is that there are lots of things different about Luau you will have to learn, and there is no reason to cater to such a specific degree.
There’s nothing that makes “mathematical correctness” any more legitimate to have analogues for than any other construct I mentioned. It’s not a slippery slope, the problem is that your core reason for wanting this feature isn’t fruitful.