From c03c31cd6ffcc692d6773b02b0215b67b36b8ec4 Mon Sep 17 00:00:00 2001 From: Arseny Kapoulkine Date: Mon, 14 Feb 2022 10:39:52 -0800 Subject: [PATCH] Update function-table-clone.md --- rfcs/function-table-clone.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/rfcs/function-table-clone.md b/rfcs/function-table-clone.md index 978dbdd4..39d2afb2 100644 --- a/rfcs/function-table-clone.md +++ b/rfcs/function-table-clone.md @@ -23,6 +23,8 @@ operation so from the ergonomics perspective it can be expected to be provided b - has the same keys and values - is not frozen, even if `t` was +The copy is shallow: implementing a deep recursive copy automatically is challenging (for similar reasons why we decided to avoid this in `table.freeze`), and often only certain keys need to be cloned recursively which can be done after the initial clone. + The table can be modified after cloning; as such, a primitive like `Object.assign` could be built on top of this. `table.clone(t)` is functionally equivalent to the following code, but it's more ergonomic (on the account of being built-in) and significantly faster: