Is there a perhaps more rudimentary explanation of this project's use case?

[kimono-koans]

I've taken a look at: https://oxide.computer/blog/iddqd-unsafe, and I'm still curious: Why would someone prefer iddqd to a BTreeSet or HashSet? You say:

But that has the risk that the emails stored in the key and the value fall out of sync.

How would that happen?

What I see is a Map acting like a Set, which makes sense, if you really need access to keys for some reason, if, for instance, you want to dump all the borrowed keys at once, or something like that (?). But I suppose I am still failing to see the motivating purpose. Could you make this more concrete for me?

Example: "A HashSet would be too slow for our purposes because it would require loading an entire value into memory... (for some reason??)."

Perhaps I haven't read your post carefully enough. Perhaps you could direct me to what I may be missing?

[sunshowers]

You can achieve some of the same goals using a set over a newtype wrapper whose Eq/Ord/Hash etc impls project down to the key fields. But the Rust set types do not allow mutation in place so you wouldn't be able to have get_mut, the Entry API, etc, without using interior mutability.

There's also no way to write the multi-index maps (Bi/TriHashMap) with that pattern, while the index + flat list pattern works quite nicely with them. We have a need for these maps at Oxide, and they share most of their internals with the single-key maps.

[kimono-koans]

You can achieve some of the same goals using a set over a newtype wrapper whose Eq/Ord/Hash etc impls project down to the key fields. But the Rust set types do not allow mutation in place so you wouldn't be able to have get_mut, the Entry API, etc, without using interior mutability.

Ahh. Thank you.

There's also no way to write the multi-index maps (Bi/TriHashMap) with that pattern, while the index + flat list pattern works quite nicely with them. We have a need for these maps at Oxide, and they share most of their internals with the single-key maps.

Ah. The crux of it. Above, I wondered if get_mut is such crazy lift, but if you need multiple indexes, I guess this makes more sense.

All of this feels like a database. I hope I'm not prying (too much) but can you describe how you might use this, and why this makes sense? As compared to say using a database?

[sunshowers]

All of this feels like a database. I hope I'm not prying (too much) but can you describe how you might use this, and why this makes sense? As compared to say using a database?

Yeah, absolutely: iddqd, embedded databases like SQLite, and networked databases like Postgres or (at Oxide) CockroachDB are all reasonable points on a spectrum. For us, many of our use cases for iddqd are for in-memory versions of rows read from a database. But we have plenty of other structs that are purely in-memory and for which the overhead of dealing with a relational database (with its schemas and such) isn't quite worth it. So we pick the right tool for the job.