Multi-return for LL functions where it makes sense by design
Nexii Malthus
There are functions where it makes sense to make use of the ability for functions in SLua to return multiple values, that is at least where the list would have been static and returned around or less than 4 values. Here are a few usecases where this make sense:
LLEvents:on("on_damage", function(events)
for _, ev in events do
local damage, type, original = ev:getDamage()
end
end)
llGetBoundingBox:
local min_corner, max_corner = ll.GetBoundingBox(object)
llGetPhysicsMaterial:
local gravity, restitution, friction, density = ll.GetPhysicsMaterial()
llLinksetDataDeleteFound:
local deleted, skipped = ll.LinksetDataDeleteFound(pattern, pass)
---
There are many other functions where it does NOT make sense however, for example llCastRay, etc.
However functions that have a fixed list of values and where there isn't an unmanageable amount (less than or equal to 4 return values I think), multiple return values make sense.
Note that unlike many other programming languages, multiple returns are actually very natural in Lua and part of many standard library functions. Even looping through array-like or dictionary tables you would use the handy ipairs/pairs functions with their multi returns.
Log In
H
Harold Linden
I'm open to the idea, but it _would_ introduce some API asymmetry between LSL and SLua...
unpack()
around the function call would do more or less the same thing, right?Nexii Malthus
Harold Linden the asymmetry here is in language features rather than design -- LSL doesn't have null but it made sense to tweak functions to support that, no?
The first step was already taken to tweak functions to fit better in SLua when you did changes for nil, so you have already gone ahead with asymmetry.
Likewise the same way you would destructure the info from llDetectedDamage was painful in LSL, having to call a list function to unpack the values many times in a tight loop for an event that should process as fast as possible. You are asking that we should call a function to unpack the values. Is it the same? Yeah. Is it what I would expect from a library function? no.
Multi return is a natural part of programming in Lua/Luau, being of many standard library functions already.
My personal agenda here is both convenience and performance, is it a natural way to program in Lua and for the tight perf sensitive loop of damage events is it also more performant?
H
Harold Linden
Nexii Malthus: Indeed, yeah I think it would make sense for a number of
ll
functions that return a fixed-length list just by virtue of LSL not supporting multi-return or objects.I don't expect it to be contentious but I'll ask what folks thing at the next SUG meeting.