Issue #21853 has been updated by Eregon (Benoit Daloze). One tricky aspect about `RUBY_TYPED_EMBEDDABLE` is if in the `struct` there is a pointer to inside that `struct` then those pointers will become invalid when the object is moved. Is there a way to handle that correctly to update such pointers? If the `struct` is ever passed to a native library I would consider it extremely dangerous to use `RUBY_TYPED_EMBEDDABLE`. Overall it sounds quite error-prone, also considering there is no safeguard to avoid writing to `DATA_PTR`, so I'm not sure it's appropriate to expose this to user extensions. ---------------------------------------- Feature #21853: Make Embedded TypedData a public API https://bugs.ruby-lang.org/issues/21853#change-116697 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- 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/