can I just double check there’s no point in using ipairs and pairs anymore?
(Couldn’t find a straight up answer online)
ipairs is better and more efficient when you want arrays and dictionaries to be in order.
pairs, however, just run through a list.
Hope that helps!
Check this post if you’re still confused:
I’m talking about neither.
I’ve just always used neither
for i, v in Array do
-- something
end
I’ve always done it this way is this bad? should I use ipairs and pairs?
If pretty much everyone else does it, I’m pretty sure it is.
I honestly didn’t know you could do that-
Anyways, ipairs is better when you’re making some sort of leaderboard since it prints arrays in order.
the way I do it
it’s always in order when it’s an array
but it’s never in order when it’s a dict
isn’t that what you want, right?
so I just don’t see the point of adding ipairs and pairs when you could just leave it out
I don’t know how your version works though. I ran it through Lua.org and it kind of bugged out. When I do pairs, it works again.
But I guess if your version works, you do you.
I’m surprised you don’t know about it
It’s not available in lua but it is in Roblox studio’s LuaU
so it will work in Roblox but not in normal lua
I thought Roblox studio removed the need for ipairs just to make it easier
I’ve never tried before lol.
Well, I guess if you ever need an unordered array, you can use pairs. If your version actually works (I can’t test rn, I’m on a chromebook), then you probably don’t want to use ipairs. (It’s not useless but if you don’t want to type an extra 5 characters…)
I have a game right now with 20K lines of code and I’ve never once used either
pairs
is capable of returning the key in Dictionaries, while ipairs
only returns the value’s position as a number.
So in conclusion, if you don’t need the key, you any. But if you want to access the key:
- for Dictionaries use
pairs
, - for Arrays use
ipairs
.
pairs
is more of a universal one, so if you use it in place of ipairs
, it won’t make a difference.
you’ve completely ignored what we talked about
If you use neither, then it returns the key but also keeps arrays in order
so isn’t that perfect for everything?
There’s already a post made about this:
luau’s new way of iterating, without using pairs and ipairs, is quite general and its goal was to eliminate pairs and ipairs to make iterations simpler.
- First, the traversal goes over numeric keys in range 1…k up until reaching the first k such that t[k] == nil
- Then, the traversal goes over the remaining keys (with non-nil values), numeric and otherwise, in unspecified order.
Because of these rules, pairs is deprecated, but ipairs can still be used in case you have mixed tables and you only want to iterate on the array side. Although using mixed tables is rare, they still exist and ipairs will never disappear completely.
Are you saying that pairs
is or will eventually get deprecated? I have not seen any announcements regarding about this change.
reading the article you will understand why I said that. it is still a proposal.
It seems the status is “Implemented” though? Or am I misunderstanding the meaning of “implemented” in this context?
The only mention of generalized iteration is from this announcement, but it is indirectly mentioning it as the main topic is about the deprecation of some table
functions.
The article is a proposal to replace the way iterate in lua, in luau it has already been implemented. It is proposed to use a __iter metamethod and a default iterator function.
In conclusion there’s no longer any use for pairs() as for i, v in Table do
does the same thing.
Ipairs() on the other hand has some rare scenarios where it needs to be used such as mixed tables.
But overal 95% of the time you should just use for i, v in Table do
no matter whether it’s a dict or an array
I know this is kind of minor, but I want to add the caveat that pairs
/ipairs
retains default functionality for tables in which the __iter
metamethod is defined. Take, for example, this structure which, when iterated over, returns its first and last values, if they exist.
local WeirdTable = {}
function WeirdTable:__iter()
local co = coroutine.create(function()
if #self > 0 then
coroutine.yield(1, self[1])
if #self > 1 then
coroutine.yield(#self, self[#self])
end
end
return nil
end)
return function()
return select(2, coroutine.resume(co))
end
end
local t = setmetatable({1, 3, 5, 7}, WeirdTable)
for i, v in pairs(t) do
print(i, v) --> 1 1, 2 3, 3 5, 4 7
end
for i, v in t do
print(i, v) --> 1 1, 4 7
end
This probably won’t be relevant to most development, but it is something to keep in mind for anyone who is defining or is using something that implements a custom __iter
method.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.