I guess if you want to return nil or false in some situations, using logical operators will break your code. For example:
local a = (b==c and nil) or (b>c and false) or (b<c and true)
I guess if you want to return nil or false in some situations, using logical operators will break your code. For example:
local a = (b==c and nil) or (b>c and false) or (b<c and true)
The following practical code does not work as expected with the and/or pattern:
local myObject = nil
local myDefault = Instance.new(...)
local condition = true
print(condition and myObject or myDefault) --> myDefault... ??
It turns out that this situation is extremely easy to run into in practice, and has been the cause of a lot of bugs in our Lua code, especially related to fast flagging since fast flagging often involves branching in table creation expressions etc which was most easily done with and/or.
There’s currently no performance benefit to freezing. We are considering an optimization for metatable lookup where frozen metatables will be faster in OOP scenarios but this hasn’t been designed yet so for now I would not recommend making performance-related assumptions here.
Another similar example for this type of error is when the “true” alternative is a boolean with the value false, e.g.
local fooHidden = foo and foo.hidden or true
always evaluates to true
, although false
may be intended when foo.hidden == false
.
Wouldn’t you use math.min for that?
There is a problem with indentation and end autocompletion when using if expressions:
Luau (+ studio autocomplete!) is my favorite feature of roblox.
Keep it up!
__close would be better as __destroy
for Luau.
As a temporary workaround, you can wrap the expressions in parentheses.
Will the new Luau be forced?
I dont wanna learn an entirely new coding engine after I just finished learning Lua.
Luau is an extended version of lua. In fact, Roblox has used luau for some time already.
If you’ve learnt to code in lua there’s absolutely no difference other than some handy additions we didn’t get in the original lua. And those differences are way too small to call luau an entirely different language, or even engine.
You’re already using Luau if you write any code in roblox. Luau is meant to be easy to adopt if you know Lua and is completely backwards compatible.
You’re already using LuaU right now as you write your roblox code. I think you mean strict type checking instead, which likely won’t ever be forced; as it would break every existing game not using it.
Yeah this is known, I believe we’re fixing this.
this works:
local isCool = false
local realResult = (isCool and 'isCool is true!!!') or 'isCool is not true'
print(realResult) -- < this returns 'isCool is not true'
i would LOVE if you could simply do:
local isCool = false
local realResult = isCool ? 'isCool is true!!!' : 'isCool is not true'
print(realResult) -- < returns 'isCool is not true'
hear me out… what if we also added this so it also works + has a good appearance
Unfortunately :
cannot be used for this in Lua because it’s already used for method calls:
Consider: a = b ? c : d() : e()
Is that: a = b ? (c:d()) : e()
or a = b ? c : (d():e())
?
What about using ||?
Example:
local enabled = false
local example = enabled ? 'I am enabled.' || 'I am not enabled'
print(example) > returns 'I am not enabled'
( or if possible change “||” into “|”)
At that point there’s little value over something more readable using if / else
(like what we chose) because it doesn’t match other languages anymore.
I think that you have a good point, but Luau is already unique – why not add one thing that isn’t unique?
local result = if isCool then 'I am cool' else 'I am not cool'
can be shortened a good amount, into
local result = isCool ? 'I am Cool' || 'I am not cool'
It’s readable and although other languages use it, I think that it can be used in Luau as well to slightly reduce the developers’ time spent writing code.