I realize returning
nil out of bounds is less "friendly"-seeming, but after reading another post in here, I realized it's way more useful.
For one thing, it should make this work:
plain_text = "my thing that is mine" label = "" for c in all(plain_text) do if c == ' ' then label ..= '_' else label ..= c end end print( label ) -- "my_thing_that_is_mine"
(Right now it never stops because the iterator keeps seeing
"" instead of the
nil it needs to terminate.)
And for another, returning a nil is much more likely to alert a programmer that their code is probably malfunctioning than returning an empty string. Accessing out of bounds is usually erroneous and should therefore trigger errors.
I realize some apps are probably already abusing the fact that you get an empty string when referencing past the end of the string, but really that's a bad programming pattern to be teaching people anyway. It's lazy, you should know where the end of the string is and stop there instead of expecting the OS/API to be your nanny and stop you from walking off of a cliff.
Presumably this should apply to negative offsets as well, meaning negative offsets big enough to go back past the start of the string.
Side note: I realize that having
all() even work somewhat is just a happy side effect of having indexable strings, but hey, some of the best discoveries are unexpected.
(It'd be nice if
ipairs() worked too, but I think that's less reasonable to ask for, since I expect it'd be more work under the hood to add support.)
Actually, now that I think about it, it seems way more consistent/orthogonal too. When you reference a table sequence out of bounds you also get
nil, and the indexed strings are mostly behaving like sequences of single-char strings, e.g. indexing
"hello" acts like you're indexing a table like this:
I like the consistent/orthogonal argument. lua uses nil really effectively and it makes sense here -- you're either returned the character you were looking for, or nothing.
a possible counterargument:
string.sub returns empty strings when you go out of bounds (https://www.lua.org/manual/5.4/manual.html#pdf-string.sub), but this maybe makes more sense because it can return strings of any length, and the empty string is a nice "nothing" value in that context. especially since one index can be in-bounds and the other might be out-of-bounds. in contrast, pico-8's
mystr[i] returns either 1 result or nothing, and I think nil makes more sense there as a "nothing" value
ord as well as lua's
string.byte both return nil on out-of-bounds indexes
luau has some nice minimal syntax additions to lua, but they don't seem to have added string indexing afaict, darn.
I dunno, it's a hard decision. I'm glad I'm not the one that has to make it! IMO consistency/orthogonality/language-predictability is the important thing, but it's not 100% clear which choice is the more consistent one here... still, I'm +1 overall
I feel kinda indifferent but if I did use this string indexing more I use falsey lookups all the time in my logic so I think it makes sense
There wasn't any good reason to go for "" except to match sub() behaviour, and I much prefer all of these arguments for nil. Especially the emergent all(str) pattern. (ha!)
Also I think it is easily worth a bit of backwards compatibility breakage -- I'll add this for 0.2.5d
[Please log in to post a comment]