I think it would be really convenient if bools could be treated like (1 bit?) integers like they are in C
true = 1
false = 0
This would mean stuff like: print(true + 1) -- 2
Would be valid
This would remove the need for messy ternary statements or if statements in code and would overall make the developing experience better
For examle instead of doing:
if bool then
something = something + 1
end
we can now do:
something = something + bool
No support from me, as this would cause major issues with future bugs that may not be apparent right away for anyone who is either new to Roblox Lua or an experienced vanilla (or other) Lua scripter.
This would also mean adding extra tests to the arithmetic opcodes in the vm which could potentially make large calculations slower than they already are.
No support. Bools should not be treated as integers.
0 is not the same as false. If you make false = 0 then false = true.
> if 0 then print 'nul' end
nul
> if false then print 'false' end
>
No, absolutely no.
Treating booleans loosely as numbers is a mistake, and that’s why recent languages don’t allow you to do this.
If an if statement for doing something conditionally is burdensome, you’re doing something wrong.
There’s several trivial solutions you can do in your own code without adding a footgun to the language:
local N = {
[true] = 1,
[false] = 0,
}
......
something = something + N[bool]
You would just end up breaking scripts that rely on the current behavior to function correctly, that is a big nono.
This isn’t exactly correct. In C, 0 is used to mean false, but anything not 0 (1, -1, 42, etc) can represent true. I would imagine change would cause other problems as stated above.
oh nno
There is a reason why C++ introduced true and false as fundamental datatypes: to exterminate the existing implicit type coercion present in C regarding bools and integers.
There has been really bad cases of developers doing things they shouldn’t be doing to C bools, such as int ops, and some really messed up code was given birth due to that.
something = something + bool
Is a perfect example of that. It’s as bad as spamming gotos, in the sense that it makes the code unreadable for literally everyone - even the programmer itself.
The problem is that in Lua, the only ‘false’ values are false and nil. If false becomes 0, then false becomes true as it is not nil. Any boolean value (such as .Changed listens to or the booleans in humanoids) would never return false, in turn breaking mostly any logic relying on humanoids and boolvalues.
While I don’t support this idea, I am curious as to what brought you to this statement. What is the use case for this feature request and where exactly would you need this?
The example use case is when I would use this the most
Some alternatives:
something = something + (bool and 1 or 0)
local boolInt = {[false] = 0, [true] = 1}
something = something + boolInt[bool]
if bool then
something = something + 1
end
I agree that changing this behavior would be bad. All of the reasons why are already discussed.
JavaScript does some implicit casting that allows adding true and 1 but the whole language is built that way. Lua is not built that way. I don’t think it makes any sense for Roblox to fundamentally change how Lua handles types and I don’t think Roblox would want to either.
Sorry if I’m bumping this a bit too late but it would be cool if we could do something like this :
tonumber(true) --1
tonumber(false) --0
Could you not just write your own tonumber function for that?
local tonumberReal = tonumber
local function tonumber(n)
return if n == true then 1 elseif n == false then 0 else tonumberReal(n)
end
The issue here is that changing the way builtin functions work doesn’t guarantee backwards compatibility. Even if the cases of relying on tonumber(bool) to return nil are rare, I am sure there are at least a few cases.
I have already my own function for this but it would be more easier if roblox had already the function :
local function ToNumber(v)
return tonumber(v) or v and 1 or not v and 0
end
And I believe there’s many case where people want to return in a multiplication 0 if something is false in the calcul I mean look at this exemple :
Frame.Position = UDim2.fromOffset(Origin.X - X * tonumber(Difference.X > 0), Origin.Y - Y * tonumber(Difference.Y > 0))
But I can only to do that :
Frame.Position = UDim2.fromOffset(Difference.X > 0 and Origin.X or Origin.X - X, Difference.Y > 0 and Origin.Y or Origin.Y - Y)
I hope you will understand what I mean and have a nice day !!!
That’s what I was thinking.
Also I optimized that function:
local tonumberReal = tonumber
local cases = {
[true] = 1,
[false] = 0,
}
local function tonumber(n)
return cases[n] or tonumberReal(n)
end
Who even uses if then expressions in situations where it negatively effects readability more than runtime behavior?
Using a lookup table here is almost definitely slower and less readable. This is a great use case of if expressions, honestly.
My stance has always been the same here
tonumber(false) --> 0 implies that 0 is a falsey value (it isn’t), which creates an incosistency with the language as a whole.
Now that shorthand if statements exist, surely it would be easier to just do, without breaking consistency in the language
if x then 1 else 0
This is probably the case so please ignore my 5 AM delusion.
Agree to disagree.