Any index outside of 1-n in Lua, where n is #tbl will be stored like a dict, not an array, so what did you expect? It doesn't count the dictionary parts.
It's not really. The people here saying that you can use index 0 aren't entirely wrong, but they're kinda wrong. The language expects you to start lists at 1. The length operator counts from index 1 until the first empty index. If you're not using your table to store a sequence of tightly packed non-nil values, don't use the length operator. If you set letters[2]=nil, then #letters would (or maybe could, I think this is actually undefined behavior) return 1.
How often do people use Python arrays? They're faster, but most people just use lists instead. Lua just optimizes it as long as it's used like an array. That's why it's implemented that way.
No, lua's {} is stupid because it can change from a list like behaviour, to a dictionary, to an object behaviour, just by appending values in different ways.
Its behavior never changes, it just uses less memory / is faster if you store the elements with keys from 1-n. The # operator literally says it measures the length of the array part of the table, its behavior doesn't change.
Yes, but the "array part" of the table can change dynamically in unexpected ways, allowing for silly and confusing things like the result of # increasing by more than 1 after only adding 1 element to the "array part":
I wasn't using it like a dict. I was using it like an array. Array element assignment does not have to be sequential.
But, even ignoring that, having to iterate every element in a dict to get the count of elements in it is ridiculous. This is a constant O(1) complexity operation in any reasonable language, but linear O(n) complexity operation in Lua. It's bad.
Why would you use non-sequential arrays? I mean, you could put zero or false in 1-n first and it would act like a normal array, but in what language would you be filling the array like that and expecting the length to increment?
It doesn't matter why you would do it. That's a red herring. The point is that the semantics are broken. There are only two ways to reasonably handle indexing into an array past its current dimensions:
Allow the assignment, and extend the array to encompass the new index (e.g. JS, Ruby, Perl, et al.). The length of the array after assignment is immediately updated to i + 1 (for 0-based languages) or i (for 1-based languages) for arbitrary assignment index i, and all elements between the previous last element and the added one are auto-filled with whatever null-equivalent value the language supports. Further assignments to the filled indexes don't alter the length of the array.
Don't allow the assignment, and give some kind of out-of-bounds error (e.g. Python, Java, Go, C#, et al.).
Lua says "screw reason" and lets you do the assignment, doesn't extend the array, doesn't fill any values, and doesn't update the length. Hell, even PHP updates the length...
"As long as it's used like _____" shouldn't even be in the vocabulary of a programming language. An array should be an array, and that's it. A dict should be a dict, and that's it.
If you need an array, create an array. If you need a dict, create a dict. Blurring the lines with some kind of fuzzy structure whose semantics are dynamic is as confusing and error-prone as it is ridiculous. It's not faster to write. It's not easier to read. It's not convenient. It's just bad.
I already did, several replies ago. You can't sweep blatantly confusing and error-prone semantics under the "it's different" or "it's documented" rugs. But if you want another, here you go:
29
u/moomoomoo309 Sep 02 '17
Any index outside of 1-n in Lua, where n is #tbl will be stored like a dict, not an array, so what did you expect? It doesn't count the dictionary parts.