Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Support an additional (optional) key in iddqd::IdOrdMap (“BiOrdMap”)

Abierto
  • ¿Algo no está bien?
#19 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Tranquilo
Stack tecnológico
rust
Área
backend

Línea de trabajo

Empieza leyendo la API existente de IdOrdMap y su comportamiento actual de indexación. Revisa el diseño propuesto de BiOrdMap y las cuestiones relacionadas con el constructor, el índice y la iteración; después, establece la API prevista y las compensaciones de rendimiento antes de la implementación. Se considera terminado cuando el diseño esté acordado y el comportamiento del nuevo mapa esté cubierto por las pruebas adecuadas.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

I love this crate, thank you for all the work!

Quick notice: I’m happy to help drive this feature, but my bandwidth is very limited for the next 6 weeks.

Background
IdOrdMap<K,V> today maintains exactly one sorted key. I need one primary index (sorted) and a secondary key for fast lookup, without being forced to rebuild maps or sort on the fly.

I began this on Reddit but it’s complex enough to merit an in-repo API discussion.

Options

  1. Only primary sorted + secondary lookup
    • Simple, but if you later need to sort by the second key, you’re back to ad-hoc sorting or a separate map.
  2. Two always-sorted keys
    • Two B-trees under the hood; higher memory & insertion/removal cost.
  3. Primary sorted + optional sorted
    • Zero-cost if you don’t invoke the second sort.
    • API is trickier: needs either builders/constructors or trait-gated impls.

API Questions
• Should one hard-code a .with_secondary_index() constructor, or infer “sortable” from K: Ord + Clone?
• Does one expose separate .iter_by_primary()/.iter_by_secondary() methods, or a unified .iter(Index)?
• Is it better to have separate BiOrdMap vs. a single generic type with optional indices?

Initial Proposal
Introduce a BiOrdMap<K1, K2, V> that always provides:
• Primary sorted index on K1
• Secondary unsorted lookup by K2

This stays close to the existing API, provides a playground to refine constructors, method names, and performance trade-offs, and lays groundwork for an optional‐sort variant later.

Feedback and real-world use cases welcome!

Lenguaje dominante
Rust
Estrellas
411
Forks
16
Merge medio
21 min
PR fusionados (30 d)
2

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de oxidecomputer/iddqd

Todos los issues de oxidecomputer/iddqd

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.