You can’t cut off all errors though. Some errors such as those due to security levels would definitely have to remain which is were things get more murky on whether that’s a good solution.
Personally I’m partial to the solution of __index taking an additional argument.
I love all the fantastic updates that always come each month with Luau. Reading these recaps for the month is like opening a present on Christmas. Thanks for all the hard work to make Luau a truly fantastic language to work with.
Specifically, being able to iterate over objects and tables directly is such a convenient thing to have! So long pairs() and ipairs() (for now)!
Can’t wait to see what we will get next month!!! 
(post marked for deletion for privacy reasons)
Would it be possible to add support for the __len metamethod for tables now? I been using the newproxy() for the __len support and it be nice to have that for the tables so I can use both the __iter and __len
Love the improvement to garbage collection! In the past I’ve struggled a lot with maintaining smooth performance, since GC would randomly decide it wanted to do a bunch of work on one frame and cause a nasty stutter.
Is there any documentation for this? I’d like to read up on it.
Also, I see there are improvements to garbage collection, any chance we could see an implementation of the __gc metamethod? 
Nice update 
Are you adding a way to narrow types by returning from a type check?
local function t(player: Player)
local character = player.Character -- Model?
if character == nil then return end
-- Still thinks character could be nil
local humanoid = character:WaitForChild("Humanoid")
end
as a workaround for now, you can add assert(character) right after the if-statement.
Hopefully the example in the recap is sufficient (also here Syntax - Luau); if you want a very thorough description you can read the full RFC (https://github.com/Roblox/luau/blob/master/rfcs/generalized-iteration.md)
Yeah we’ve discussed this as a potential next step, as with __iter this is the only metamethod you’d need to fully implement an indexed container. We’d need to be careful wrt potential performance impact, but we plan to look into this at least.
yeah not a bad idea, although a bit ugly
I recall something about constant-type type-checking (e.g. strings, numbers, booleans, etc):
type constantStringABC = "ABC" -- Type matching only the string "ABC"
Is this still a planned feature? I find a lot of times I want to use this, particularly for enum-like types, like tables containing different parameters based on a particular key’s value which could be a set of constants.
(Type enums would actually be cool but that’s a different topic)
I really don’t like “generalized iteration”. I’m going to continue using pairs and ipairs explicitly. Please don’t ever deprecate them.
I think that’s called singleton types and IIRC that’s already live?
Indeed it is, I’m surprised I missed this.
I like this quite a lot, but I agree with you otherwise.
It is proper to use pairs when you expect/desire a table (and ipairs doesn’t get replaced by this at all since it is fundamentally different than pairs). If your use case is actually just iteration on the other hand (not usage of a table), this feature might be what you want, and, there’s been a few times I really wish I could’ve used this.
While it’s up to you whether to continue using pairs/ipairs, there’s not really a benefit to using pairs or ipairs explicitly. I don’t think the word “proper” is, well, proper in this case 
We specifically made sure that they don’t need to be used when iterating over tables or array-like tables.
That said obviously we don’t have plans to deprecate pairs/ipairs, so if people prefer them stylistically for some reason it’s fine to continue to use them.
Yeah I suppose I worded that poorly, I’m glad you pointed that out. I meant to emphasize that it’s a little more descriptive about intent, e.g. the input is expected to be be a table (which will have key value pairs) vs any old iterable, which can definitely matter.
There’s definitely no objectively correct choice for tables because functionally they’re the same, and which one you use probably won’t won’t really change how easy it is to scale up code or anything, but, it might sometimes be preferable to use pairs because of its explicitness.
I am definitely happy all around with the feature so far 
I have a problem with the __iter metamethod’s implementation.
I have a sandboxing tool here which wraps around objects with metamethods. In order to do this though, I need to be able to essentially generate a copy of the original metamethod without touching that metamethod (I use this for values going in AND out of the sandbox, so some values I need to wrap are going to be unmanaged!)
With the __iter method, there does not exist any function which can return the generator, state, or index produced. pairs throws because the input is not a table, as I feel it it should.
In the RFC, it is noted that the equivalent of how t[index] is to rawget(t, index) is as in t is to in pairs(t). This is true, however, t[index] can be invoked as an expression, meanwhile getmetatable(t).__iter(t) cannot be safely invoked as an expression, and I can’t access the generator, state, and index and therefore these values go unsandboxed, providing a way for users to define code in completely unmanaged space which can access unmanaged values, even from my own managed tables.
Additionally, I am even unable to do something smart like the following, wrapping a real iterator inside of a coroutine, and returning a function which advances the state by resuming it repeatedly. The generator can return a variable number of results but I can only capture a finite number of results.
This example which mimicks the structure I require runs as expected, but only if the iterator uses two or less arguments. A vararg is not valid syntax. Very very thankfully, iterators cannot yield, but if they could, this example would be invalid for that reason because it would cause the two iterators that end up processing to lose their synchronization.
local metatable = {}
local proxy = {}
-- Psuedo-code
local function getUnmanaged(value)
return {
abc = 123,
cde = 234
}
end
local function sandboxAllTheResults(...)
return ...
end
metatable.__iter = function(sandboxed)
local real = getUnmanaged(sandboxed)
return coroutine.wrap(function(x)
-- Instead of index, value, if a vararg (...) were placed here it would cause a syntax error
for index, value in x do
coroutine.yield(sandboxAllTheResults(index, value))
end
end), real
end
setmetatable(proxy, metatable)
-- cde 234
-- abc 123
for index, value in proxy do
print(index, value)
end
So, there are two solutions that solve this:
__iter metamethod directly (Preferable to me since it allows me to manage the generator itself)c.c. @zeuxcg
Why not? I’m a little confused at the description above, but short of tables with locked metatables (which you can’t introspect reliably, but neither can you introspect any other metamethod so I don’t see how you can wrap an object with a locked metatable in general), you should be able to return a proxy that forwards __iter. For example:
local function proxy(v)
local function proxyiter()
print("proxyiter")
assert(type(v) == "userdata" or type(v) == "table")
local mt = getmetatable(v)
if mt and mt.__iter then
return mt.__iter(v)
else
assert(type(v) == "table")
return next, v
end
end
return setmetatable({}, { __iter = proxyiter })
end
for k,v in proxy({1,2,3}) do
print(k,v)
end
local mt = {}
function mt:__iter()
local index = 0
return function()
if index >= self.count then
return
end
index += 1
return index
end
end
for i in proxy(setmetatable({count = 3}, mt)) do
print(i)
end
P.S. Maybe the confusion is that you aren’t sure how many results __iter can return, but it can return at most three, so if you want to wrap/proxy functions somehow you can instead do:
local gen, state, index = mt.__iter(v)
-- do some work on gen/state/index
return gen, state, index
The Lua iteration protocol, which __iter follows, only uses three values - generator, state, and index (which is fed into the generator repeatedly on every iteration and becomes the first loop variable). __iter doesn’t change that.