boolean to integer conversion | Voters

boolean to integer conversion

Wulfie Reanimator

SL's implementation of Lua now has three number-ish types:

number
(built-in)
boolean
(built-in,
false
is distinct from
0
)
integer
(userdata, for compatibility with LSL API)
integers can be created from numbers by calling
integer()

Right now, we can't convert

boolean

integer

, which makes writing scripts a bit convoluted:

enable = false   -- eg. result of `health <= 0`
ll.SetPrimitiveParams({PRIM_PHYSICS, integer(enable)})
 
-- error: lua_script:2: unable to cast!
--        [C] function integer

The current solution would have to be:

enable = false   -- eg. result of `health <= 0`
enable = if enable then 1 else 0
ll.SetPrimitiveParams({PRIM_PHYSICS, integer(enable)})

A day ago

animats Resident

It's easier to fix this in Luau/LSL call list parsing than explain it clearly. 
It would take about a half hour video by an influencer, plus a cheat sheet with examples of common mistakes, to explain this. Especially since errors show up at run time, not compile time.
Please, fix it so there's only one kind of "true" and "false'. Thanks

Wulfie Reanimator

I agree with this. Changing the

TRUE

FALSE

constants' values to Lua booleans and changing the way LSL lists are parsed seems to have the simplest outcome.

It also resolves a lot of the context clash between LSL vs Lua, eg.

local doStuff = FALSE   -- equivalent to zero
if doStuff then
    -- oh no, we're doing stuff!

WolfGang Senizen

Or the equally horrid

enable = false 
enable = if enable then TRUE else FALSE
ll.SetPrimitiveParams({PRIM_PHYSICS, enable})

I kinda don't like having

TRUE

true

FALSE

, and

false

.... especially as

FALSE

doesn't evaluate as false....

Wulfie Reanimator

That's a slightly nicer version. Still though!

Having implicit typecasting within lists is a whole other canny of worms. 😋

WolfGang Senizen

Wulfie Reanimator

I'm not sure it is nicer.... it's definitely more confusing to someone new.

animats Resident

I'd suggest that LSL list parameters that expect Boolean values require standard Lua Booleans. So insist on

enable = false 
ll.SetPrimitiveParams({PRIM_PHYSICS, enable})

and disallow

enable = 0 
ll.SetPrimitiveParams({PRIM_PHYSICS, enable})

That should be an error, not an auto conversion.

Yes, this will break some Lua code that a few users wrote in the last two weeks. Including some of mine. But it won't be a headache for years to come. The few people who go on the beta grid and try this alpha version of Luau can deal with that. I think we've all met.

(Implicit type conversion has a long and sad history, going all the way back to PL/1, which type-converted anything that could possibly be converted. It's a source of hard to find bugs, and has become less and less popular over the years for that reason.)

Wulfie Reanimator

re: "That should be an error, not an auto conversion."

Unless we'll actually get the

--!strict

flag for scripts, conversions are the way Lua/u works as a whole, and we shouldn't break that for special cases. The same thing applies to LSL lists as a whole; the API should accept

number

where

integer

is expected, outside of strict-mode, but I digress.