Issue #21853 has been updated by Eregon (Benoit Daloze). Were the various safety concerns mentioned above (https://bugs.ruby-lang.org/issues/21853#note-5, https://bugs.ruby-lang.org/issues/21853#note-6) even discussed in the meeting? It seems not according to the log: https://github.com/ruby/dev-meeting-log/blob/master/2026/DevMeeting-2026-03-... So we are giving a new API to users that can easily cause data corruption (due to writing to DATA_PTR), out-of-bounds access (due to compaction) and subtle GC-related bugs (due to lack of RB_GC_GUARD) and probably has no checks currently against any of those, only docs? Seems a recipe for nasty segfaults to me. cc @ko1 @matz At least we should check the parts we can, I'm adding some comments on the PR: https://github.com/ruby/ruby/pull/16455 ---------------------------------------- Feature #21853: Make Embedded TypedData a public API https://bugs.ruby-lang.org/issues/21853#change-116813 * Author: byroot (Jean Boussier) * Status: Closed ---------------------------------------- As part of Ruby 3.3, we added a private `RUBY_TYPED_EMBEDDABLE` flag to the `TypedData` API to allow `TypedData` to use variable width allocation. Technically, we inadvertently exposed that flag in public headers so third party extensions can make use of it, but it's not considered public API as it's not documented, so it would be a poor decision. This API has both memory and speed benefits as it allow to avoid some `malloc/free` churn, reduce pointer chasing, etc. For instance, when we converted `Time` to be embedded, it improved allocation performance by 30% and also reduced memory usage by 20%: https://github.com/ruby/ruby/commit/aa6642de630cfc10063154d84e45a7bff30e9103 I believe numerous third party native extensions could benefit from it (I would certainly make use of it in `ruby/json`), now that we used it internally for several years, I'd like to work on making it a public API for Ruby 4.1 -- https://bugs.ruby-lang.org/