Allow table.clone to copy tables with locked metatables

[ccuser44]

Allow table.clone to copy tables with locked metatables.

Rendered

This is a remake of the original poorly done RFC #73 . The issues in the original RFC have been fixed and the ambiguities have been clarified.

[dphfox]

Would it be intuitive for a metatable to only sometimes be copied?

[ccuser44]

Would it be intuitive for a metatable to only sometimes be copied?

Yes

[ccuser44]

I haven't finished this yet because I haven't resolved 2 of the issues levied yet.

[ccuser44]

Done

[zeux]

I don't fully understand the motivation here. Why would JSONEncode need to clone the table, as opposed to using rawget et al? Why would you want to JSON serialize something with a locked metatable?

The downside is that this RFC proposes changing table.clone behavior from "it returns a table with the same structure or fails" to "it returns a table with the same structure, or a table that has different behavior if the original metatable was locked". It's... not obvious that this is a good idea.

I also don't fully recall the scope of potential for the exploits against "clone that preserves locked metatable". Understanding this would probably require analyzing Roblox internal codebase, which only Luau team members could do.

One alternative I could see that is perhaps more sensible is table.clone(t, newmt), as it is unclear that table.clone with new behavior without an immediate call to setmetatable is useful. This comes with its own challenges, namely that you'd want to allow newmt = nil, so the implementation will have to distinguish newmt = none (current behavior) vs newmt = nil (new behavior), which is possible but something that is generally frowned upon.

But beyond everything else I think this RFC needs a use case that is actually clear and not adequately solved today.

[karl-police]

Does default Lua allow table.copy to copy with metatables, shouldn't it be an optional thing that can be copied?

[vegorov-rbx]

Does default Lua allow table.copy to copy with metatables, shouldn't it be an optional thing that can be copied?

Lua doesn't have table.copy/table.clone functions.

[karl-police]

Luau doesn't have table.copy.

table.Copy from Garry's Mod creates a deep copy by default, every entry has a new table address and if a metatable is present it will re-reference it, otherwise it would break classes.

table.clone doesn't create a deep copy, it re-references the nested table addresses (which can have a locked metatable through __metatable)

but the first table inputted into table.clone for some reason, can not clone if __metatable is present. While Garry's Mod doesn't have a problem with that. But __metatable in Garry's Mod expects an actual table.

 

Regarding table.Copy for Garry's Mod, when it comes to userdata, it is a bit different, it's not like metatables. If table.Clone from Garry's Mod is used on a table with a userdata as an assigned value to a key, the userdata's address itself seems to be copied, meaning that the value itself has a re-reference.

 

Was there ever a reason why table.clone couldn't copy the first table as a new one, with the same metatable that included a __metatable ?

[cheesycod]

From a cursory glimpse at this RFC, would this not be a sandboxing hazard if table.clone'd tables shadow cloned the table and then simply dropped the metatable?