Как называются хэш-таблицы с автоматической генерацией ключа при вставке?

Никак, кажется в вопросе какая-то ошибка

Я искал подходящий крейт, но не нашёл. Мне нужна потокобезопасная HashMap<u32, &str>, но ключ изначально неизвестен, его нужно генерировать, но тогда нужно делать проверку отсутствия ключа в таблице.

Опять же повторю, вставка идет по ключу, раскрой мысль. Потокобезопасность тут не причем

Для вставки есть значение, но нет ключа. Сценарий работы программы в том, что она должна сама сгенерировать ключ и отдать его в качестве ответа. Затем по сгенерированному ключу пользователи достают значение.

А какую задачу решаешь?

А чем это не hashmap uuid -> value? Ну или не uuid, а атомарный счётчик? И для потокобезопасности взять dashmap или rwlock Ну либо условный redis раз кеш делаете

Я делаю кэш, который в памяти хранит ключ-значение, но с генерацией ключа.

А что конкретно не получается

В случае атомарного счётчика вычислять хэш разве не дорого? Вектор с получением элемента по индексу не будет быстрее? Redis не подходит, так как код на горячем участке, сетевой оверхед.

В случае атомарного счётчика будет вычисляться хеш для просто u32, а это почти мгновенно

Сделай HashMap<u64, &str>, при вставки генери рандомное u64 число, вставляй по нему как по ключу и возвращай его. Проверяй, что такого числа еще нет в таблице. Размера u64 хватит, чтобы не иметь никаких проблем с нехваткой ключей

зачем делать рандомное?

В проверке отсутствия и заключается вопрос. Ключ генерируется, поэтому может быть инкрементальный счётчик, а для удалённых значений отдельный вектор, чтобы новым пользователям выдавать индекс из него. Но всё ещё непонятно, что будет быстрее, такая хэш-таблица или один большой вектор. Значения это ссылки на строки.

Ну кстати можно и вектор сделать, делать пуш и возвращать индекс. Тут реально хешмапа не нужна тогда

Если хранить не ссылки, а сами строки, вектор не будет тормозить? Проблема в том, что вектор для конкурентного доступа придётся делать мультиверсионным, помечать ключи как удалённые, и все сопутствующие сложности как следствие.

Такое не подойдет? Может неправильно понял, что вы хотите https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=2f5c4c354f7dbdc953b003bac9fb3dc1

У меня Point-Lookup.

Строки отдельно будут храниться, вектор это 3 слова

А ключи обязательно u32/u64 должны быть?

i32/i64 тоже могут быть.

Все сложности с версионностью уже внутри https://docs.rs/generational-arena/latest/generational_arena/ решены, но там ключи (usize, u64). В принципе, если есть гарантии что количества элементов/удалений&вставок точно меньше u32, то можно обернуть и паниковать при превышениях, ограничив ключи до (u32, u32). (хотя лучше или смириться с (usize, u64), или свою такую штуку реализовать для (u32, u32) или (u48, u16) с выжжеными ячейками, зависит от профиля использования)

Если бы не паника, то это отличный вариант.

slotmap?

А подходит под многопоточные? Или только через rwlock? А в остальном выглядит прям огненно