Harold Linden: I'm chewing on this... my back of the napkin response is mixed.

For some of the items it makes sense, the functions, for instance, if the event doesn't support the information.

I thought we'd made the null uuid falsy... so I don't see as much call for it there.

For many others (especially the float and integer functions) it would be difficult to tell from just the value if this was a failure or a legitimate 0. We'd have to implement something in the wrapper that did the appropriate checks.

Or we would need to add a failure flag to LLScriptLibData to indicate failure and update the simulator's implementations to set that flag. That might be the better approach.

Rider Linden: Mmm, is not falsey (only and can ever really be falsey due to VM reasons). It has to be checked with .

Always returning in cases where a sentinel value would be returned isn't necessarily worse than LSL, but it would _necessitate_ branching where it might not otherwise be required.

I'm somewhat torn on it, especially given the complexity of the API. I suppose we can punt on it and introduce it in a new stdlib version later if it's contentious. stdlib versioning is much less of a pain under the new scheme than it is under Mono (since it was basically never done), though I haven't used it much yet.

Harold Linden That's what I was thinking of ".istruthy"

I'm good with a punt too.

Harold Linden Hmmm,

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.

and 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 and in .

Depending on the point of view each of them could be the one (I would choose ).

It's more clear to leave it as it is.

------

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 .

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:

and returning looks very good.

And what about ?

It could return instead of , but we would have to remember not to use (it would work the same if the constant was undefined, but it can't be because llcompat needs it).

Or, should return 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.

SuzannaLinn Resident

re:

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 sentinel value, not several variations.

Plus more conventional retry later is via .

Although I admit have had to implement a retry later while loop with 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 , , then there is no reason to return 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.

Harold Linden more:

These ones do, but also shout an error, so may not count:

SuzannaLinn Resident In the case of functions like ll.GetAgentList, I vote for an empty table. This is because an empty table is the correct answer to the request, whereas a nil value generally represents an exception/error. Returning a nil value would require our scripts to respond to that value with some sort of exception processing, whereas looping through an empty list simply becomes an effective no-op, which is what the scripter will want much of the time. When an empty list is not processable as a no-op (i.e, the script needs at least one agent to be present to do whatever), then checking for a table length of 0 to generate the exceptional response is not significantly more work than checking for a nil response.

The case for reading linkset data is more complex. It seems to me that returning a nil value is only useful if we could assign "" as a valid value, but this raises compatibility issues with LSL scripts accessing the same data (Is this even an issue? Why would we be mixing LSL and SLua in the same object? Yes. Legacy objects that we're enhancing. Using no mod scripts from other sources . ) Looping through a list of existing keys, you'll never get the sentinel value. In tables, returning nil for non-existent keys and removing keys by setting their values to nil lets us treat nil like any other value when we so choose. But in linkset data, the stored value is always a string and setting the key to "" deletes the entry. So long as this behavior exists, the logical, most table-like, behavior would be to return "" for the same reason. Example, I'm using the UUIDs of the players of my game as keys, and keeping a list of achievements that they have accomplished. The list of possible achievements might be large so to save space, I only record those actually accomplished. So when I need to know if the player has achieved goal_X, I read the string associated with their key and search it for the goal_X tag. In this case "", as a return for a player who hasn't accomplished anything yet, is much more useful to me than a nil return since I don't have to make exceptions in my code for players with no accomplishment.

Bottom line: if the sentinel value can be interpreted as a valid response, then return "", 0, false, whatever, and reserve nil for cases where the sentinel value always (or at least nearly always) flags an exception that must be handled as such.

SungAli Resident Not addressing beyond the scope of what I had originally ask for here, the motivation for my request was simple: easy detection of a "non-existent key". For example

local LSDValue = ll.LinksetDataRead("no key")

LSDValue as it currently sits will be: ""

when I then test:

if LSDValue then

do something with the return

else

do something for a key that doesn't yet exist.

end

if the return was a "nil" we'd have a simple block here. But "" always return true in an if statement, so we have to extra steps to see if the return was "" or actually something we wanted. I mean, it's sot horrible onerous to be sure, but it's also less than elegant.

That was my only driver for that one and I still say it'd be useful for some functions that return "" to return nil instead just for simplicity in testing for. Returning "false" or "0" wouldn't really work here since "false" would be stored as a string value and not the boolean. and "0" might be a perfectly key-value pairing. Only nil allows for a quick, simple, and intuitive "if test". that I can see. I could be wrong. But that was my line of thought on the subject when opening this.