Issue #22232 has been updated by Eregon (Benoit Daloze). +1, exposing less internals means we can optimize more, and cleaner safer APIs. ---------------------------------------- Feature #22232: Deprecate `RHASH_TBL` and associated APIs https://bugs.ruby-lang.org/issues/22232#change-118851 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- I would like to deprecate `RHASH_TBL`, `RHASH_TBL_RAW` and `rb_hash_bulk_insert_into_st_table`. ### Problem These API take a `RHash` instance and return its associated `st_table *`. If the Hash isn't backed by an `st_table` it will force convert it. I think it's a bad API because: - It allows to mutate the hash without triggering write barriers (dangerous). - Using it on a Hash backed by an `ar_table` blow memory usage. - It restrict evolution of RHash, as we must always be able to convert a Hash into a public `st_table`. There are various optimizations that would make sense for `RHash` but that would break the public `ruby/st.h` API, as such, in the future we may want to essentially fork `ruby/st.h` to have a distinct internal version dedicated to `RHash`. Just to give an example, `st_table.type` is very wasteful for RHash, as it's a full length 8B pointer that has only 2 possible values. It would be way more efficient to pass it as an argument every time, and get rid of some pointer chasing. With the possible future introduction of arbitrary length allocation in the GC, we might also want RHash to allocate its bins and entries with the GC rather than malloc. Both those ideas aren't possible to implement (or much harder) if we need to support `RHASH_TBL`. ### Impact I need to figure out how to use the gem search server, but a preliminary search on GitHub didn't show a lot of usage, it's a relatively rare API and if there are use cases that currently necessitate using `st_*` functions on RHash we should define equivalent `rb_hash_` functions to replace them. -- https://bugs.ruby-lang.org/