Skip to content
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

Allow table.clone to copy tables with locked metatables #88

Open
wants to merge 8 commits into
base: master
Choose a base branch
from

Conversation

ccuser44
Copy link

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
Copy link

dphfox commented Dec 14, 2024

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

@ccuser44
Copy link
Author

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

Yes

@ccuser44
Copy link
Author

ccuser44 commented Jan 6, 2025

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

@ccuser44
Copy link
Author

ccuser44 commented Jan 6, 2025

Done

@ccuser44 ccuser44 requested a review from vegorov-rbx January 6, 2025 09:55
@zeux
Copy link
Contributor

zeux commented Jan 8, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

4 participants