Weird there isn't a src directory collecting everything together<p>Hashtables are one of those data structures one can easily get away with never having to write on their own, yet still use every day. In scripting languages it's impractical to roll your own, & in the more abstracted low level languages there'll usually be a pretty good generic version. Yet there's much room for variation<p>I had the joy to be out of reach of off-the-shelf hashtables for luwa,<p>init: <a href="https://github.com/serprex/luwa/blob/436c7271120fcd116af30e906919afe7a7e55254/rt/alloc.lua#L156" rel="nofollow">https://github.com/serprex/luwa/blob/436c7271120fcd116af30e9...</a><p>get/set: <a href="https://github.com/serprex/luwa/blob/436c7271120fcd116af30e906919afe7a7e55254/rt/table.lua" rel="nofollow">https://github.com/serprex/luwa/blob/436c7271120fcd116af30e9...</a><p>hash: <a href="https://github.com/serprex/luwa/blob/436c7271120fcd116af30e906919afe7a7e55254/rt/obj.lua#L130" rel="nofollow">https://github.com/serprex/luwa/blob/436c7271120fcd116af30e9...</a><p>Still need to implement Lua's sequential-portion-as-array logic. I do like the API not having a 'remove' method, opting intead for nil by default. nil value entries get vacuumed out when rehashing. This ends up acting as tombstone. In an earlier iteration I was using 0 as a marker distinct from nil, but an implementation detail is that nil is stored at address 0.. oops