Allow ll.LinksetDataRead to return nil when the key pair does not exist in the data store. | Voters

Allow ll.LinksetDataRead to return nil when the key pair does not exist in the data store.

tracked

Anna Salyx

ll.LinksetDataRead("key") and ll.LinksetDataReadProtected("key", "pass") both will return an empty string if trying to access a stored value that doesn't exist. Which is not "nil". 
Can we get it so that if a key pair does not exist in the LSD store that the return is actually a "nil" type instead? It would also return nil on a protected key with a bad "pass". 
We have access to the nil data type with SLua now, and it'd be more logical for a non-existent key to return nil for a simple boolean test. IMO.  Just an idea at least.
Added thought: 
maybe have "llcompat" have the return still be a zero length ("") string for, well, compatibility sake.

November 13, 2025

MarieOmani Resident

I would vote to keep things as they are with NAK and EOF. They mean something different than nil.

Harold Linden

marked this post as

tracked

Thanks for the suggestion! I'll bring this up at the next user group meeting to see if there's consensus.

Harold Linden

Interesting, I'll have to think about the API implications.

Are there any other obvious functions that return "" as a sentinel value when it'd be more sensible to return

nil

? Maybe the notecard stuff that returns

NAK

should logically return

nil

, or would that be weird given that it has other sentinels like

EOF

Nexii Malthus

Harold Linden Hmmm,

llGetInventoryName
returns empty string if not found this could return
nil
llGetInventoryDesc
can return empty string if item has no description but think that makes sense to have as an empty string because that's what it is. Same with
llGetObjectDesc
.
llGetDisplayName
can return an empty string in certain conditions, but also has other weird return values possible (
"???"
/
"Loading..."
). Honestly this is really messy and needs to be really fixed / unified. Just returning
nil
on: empty strings,
"???"
and
"Loading..."
llGetUsername
likewise can return
""
if unable to resolve, should return
nil
instead
llKey2Name
returns an empty string for non-existent avatars/prims, this is often used as a useful presence check in a lot of scripts, could return
nil
for same usage
llGetRenderMaterial
returns... a name, uuid or null key? Returning either string name, native uuid or
nil
would be fine here
llGetParcelMusicURL
can return an empty string, but not familiar with the function, guess it could return
nil
if not set or failing the permission?
llGetNotecardLineSync
is a bit complex yeah since it can return
NAK
or
EOF
which are not comparable to
nil

Anna Salyx

Harold Linden  I'm not sure about ll.GetNoteCardLineSync.  The NAK is specifically for cases when the notecard data has fallen out of the regeion cache.  
A dataserver function to get the number of notecard lines and to get a notecard line Asynchronously loads the notecard data into the region cache which can then be retrieve by the synchronous method thereafter.  But if that notecard data expires or is pushed off the stack, then a NAK is returned to say "hey, that's not currently available, try the other way."  So, I'm not sure "nil" if wouldn't  fulfill the same purpose. NAK just might be a functional synonym of nil.  Unlike EOF which says "no more data", NAK or nil both could say "data not currently available".
Now that all said.... My own personal preference would be to keep NAK in this case since it mentally/naturally goes hand in hand with EOF for notecard reading:  Line not available / No more data
Oh! And a zero length line should always return a zero length line of course.

SuzannaLinn Resident

Harold Linden
ll.LinksetDataWrite()
 and ll.LinksetDataWriteProtected()
 could accept nil as value to delete a key.
This way they would behave more alike to tables.
But "" should still delete a key, not set the key to "", to be compatible with LSL scripts sharing the linkset data in the same object.
------
I would stay with NAK
and EOF
in  ll.GetNoteCardLineSync()
.
Depending on the point of view each of them could be the nil
 one (I would choose EOF
).
It's more clear to leave it as it is.
------
ll.GetDisplayName
returning "Loading..." is a kind of feature, it can be used to retry later (I have used it).
It could be better to have a different return, something like a NAK, but not nil
.

SuzannaLinn Resident

Harold Linden
A bit of  philosophy...
I think that we should have clear where to stop the Lua-lization of LL functions before going on.
For instance:
ll.GetInventoryName()
 and ll.GetInventoryDesc()
returning nil
looks very good.
And what about ll.GetInventoryType()
?
It could return nil
instead of INVENTORY_NONE
, but we would have to remember not to use INVENTORY_NONE
 (it would work the same if the constant was undefined, but it can't be because llcompat needs it).
Or, should ll.GetAgentList()
return nil
 instead of an empty table?
I think that we must keep in mind that the scripters commenting in SLua canny, in Scriptting-lua discord and in SUG meetings are mostly advanced scripters.
There are many not so advanced scripters waiting for SLua in main grid to start learning it. And we are making a very long list of changes for them to learn. And all the changes are useful, but perhaps not useful enough.

Nexii Malthus

SuzannaLinn Resident 
re: ll.GetDisplayName
that's all well and good until someone decides to set their display name to "Loading..." (I've had someone on my friends list with that for years) -- plus what about "..." and ""?
The function should  return a single clear nil
 sentinel value, not several variations.
Plus more conventional retry later is via ll.RequestDisplayName
.
Although I admit have had to implement a retry later while loop with llGetDisplayName
 to avoid a complex async code workaround on a critical script important to a region.
Re: philosophy
Yeah, if there are already is a clear enumeration/constant like NAK
, EOF
, INVENTORY_NONE
 then there is no reason to return nil
 instead.
Also agree with functions that return a list to return an empty table. These can be easily checked with the native # count. E.g. local agents = ll.GetAgentList(...); local agentCount = #agents;