-
Notifications
You must be signed in to change notification settings - Fork 73
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix various issues and cleanup whitespace #9
base: master
Are you sure you want to change the base?
Conversation
- better explanation of the length operator - no functions in table constructors - spaces after { and before }
list[2] = nil | ||
list[3] = "item" | ||
|
||
print(#list) -- undefined result |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should say that it returns 1 rather than the expected 3.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With a given Lua implementation. But the definition in the language is even worse. In Lua 5.1:
any integer index n such that t[n] is not nil and t[n+1] is nil
So it could be 1 or 3.
In Lua 5.2 it is even clearer:
Unless a __len metamethod is given, the length of a table t is only defined if the table is a sequence, that is, the set of its positive numeric keys is equal to {1..n} for some integer n
So the operator could return anything. Or crash your program, for that matter. Actually I expect some later Lua implementations to raise an error in that situation.
Anyway, my point is: you cannot rely on it being 3 but you cannot rely on it being 1 either.
EDIT: If you think this undefined stuff is theoretical, guess what this prints:
print(#{1, 2, nil, 3})
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's true; maybe expand it as result depends on Lua implementation
, then?
I admit, I only tested it in Lua 5.1.5 and Luajit 2.0.2 to confirm.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it depends on the implementation. And it is not consistent even on Lua 5.1.5. As I said in my edit above, if you put the hole just one step further it doesn't give the same answer:
Lua 5.1.5 Copyright (C) 1994-2012 Lua.org, PUC-Rio
> list = {}
> list[1] = "item"
> list[2] = "item"
> list[3] = nil
> list[4] = "item"
> =#list
4
If you are interested in the "why" see the implementation. Hint: binary search.
Thanks for the cleanup! Just the one note above. |
It was very nice of catwell to provide a pull request with the applied fixes and I can not understand the hold up here. The return value of the length operator on a table which is not a sequence, and in the case of 5.2 does not have a __len metamethod, is not defined. |
@aDevilInMe No hold up, I just have been very busy and haven't had a chance to merge. Will do so, after I fix the merge conflict, once I have time. |
No description provided.