Proposition d’ajout d’un package UUID à la bibliothèque standard de Go

• Une proposition visant à inclure les fonctions de génération et d’analyse des UUID dans la bibliothèque standard du langage Go est en discussion sur GitHub
• L’auteur de la proposition fait valoir que la plupart des projets Go côté serveurs et bases de données dépendent aujourd’hui de packages externes comme github.com/google/uuid
• De grands langages comme C#, Java et Python offrent déjà une prise en charge des UUID au niveau de la bibliothèque standard
• Au fil des échanges, plusieurs points clés ont été débattus, notamment les spécifications récentes comme UUIDv7, la conformité à la RFC 9562, le périmètre des fonctions d’analyse et la cohérence de l’API
• La proposition a ensuite été fusionnée dans une autre proposition en cours, ajoutant la prise en charge d’UUIDv4 et UUIDv7 au package crypto/rand (#76319)

---

Aperçu de la proposition

• Proposition d’ajouter à la bibliothèque standard de Go une API de génération et d’analyse d’UUID
  • Versions visées : UUID v3, v4 et v5
  • Principaux arguments : la dépendance aux packages externes et l’existence d’un support standard dans d’autres langages
• Les UUID sont un standard international défini par la RFC 4122 (puis par la RFC 9562)
• L’auteur souligne que Go constitue, parmi les grands langages, un cas exceptionnel sans prise en charge standard des UUID

Réactions initiales et discussions

• Certains participants ont rappelé que des propositions similaires avaient déjà été soumises par le passé puis rejetées (#23789, #28324)
  • Motifs invoqués : l’usage de packages externes est suffisamment simple, et leur cycle de publication est plus flexible que celui de la bibliothèque standard
• L’auteur rétorque que si la plupart des projets doivent importer un package externe à chaque fois, il vaut mieux l’intégrer directement au standard
• Le fait que de nombreux langages incluent les UUID dans leur bibliothèque standard liée à la cryptographie a aussi été avancé comme argument en faveur de la proposition

Prise en compte des versions récentes d’UUID et de la RFC

• Certains avis estiment que les UUID v1 à v5 sont dépassés, et que v7 est la version la plus récente et la plus prometteuse
  • v7 laisse place à diverses options d’implémentation, et il est jugé utile d’observer les retours d’usage
• Le brouillon de la RFC recommande de ne pas analyser les UUID inutilement et de les traiter comme des identifiants opaques
• Après la publication officielle de la RFC 9562, la discussion s’est déplacée vers une prise en charge centrée sur UUIDv7

Révision et fusion de la proposition

• En 2025, après la formalisation de la RFC 9562, il a été mentionné que PostgreSQL 18 prend en charge UUIDv7
• Côté Go, une proposition distincte a ensuite été lancée pour ajouter uniquement les fonctions de génération d’UUIDv4 et UUIDv7 au package crypto/rand (#76319)
  • Les fonctions d’analyse en sont exclues conformément aux recommandations de la RFC
• La proposition initiale (#62026) a été fermée comme doublon

Discussions sur la conception de l’API

• Débat sur le comportement par défaut de uuid.New() : faut-il le fixer à v4 ou laisser la porte ouverte à un changement futur ?
  • Certains estiment qu’un changement de version poserait des problèmes de compatibilité, et proposent donc de le figer définitivement sur v4
• Discussion sur l’ajout de méthodes comme Compare, MustParse et Parse
  • Pour certains, Compare est nécessaire afin de prendre en charge les UUID pouvant être triés, conformément à la RFC
  • MustParse serait inclus pour rester cohérent avec les autres fonctions Must* de la bibliothèque standard
• Il a été conclu que la méthode IsZero() n’était pas nécessaire pour un type UUID
• Diverses pistes de conception ont été proposées, comme l’introduction d’une structure Generator ou la séparation par types selon les versions (UUIDv4, UUIDv7, etc.)
• Certains ont aussi jugé la fonction New() trop ambiguë et proposé de ne fournir que des fonctions de version explicites (NewV4, NewV7)

Principaux enjeux techniques

• Débat sur le point de savoir si la définition du tri des UUID n’est clairement établie que pour v6 et v7
• Examen des méthodes d’implémentation permettant de garantir le tri temporel lors de la génération d’UUIDv7 et d’éviter les collisions en concurrence (via un mécanisme de compteur)
• Des différences de sens selon les versions — par exemple, v1 inclut une adresse MAC tandis que v7 est basé sur le temps — ont mis en lumière les limites d’une conception à type unique
• Certains ont proposé de séparer les types par version et d’ajouter des méthodes de conversion explicites comme AsV4() ou AsV7()

Conclusion et état actuel

• La communauté Go semble globalement d’accord sur la nécessité d’un support standard des UUID
• Cependant, afin de préserver la simplicité de la bibliothèque standard et de respecter les recommandations de la RFC :
  • les fonctions d’analyse sont exclues
  • seules les fonctions de génération d’UUIDv4 et UUIDv7 seraient ajoutées à crypto/rand
• La proposition initiale (#62026) a été intégrée à la proposition #76319 et suit désormais cette voie,
  ce qui place la prise en charge standard des UUID dans Go à un stade proche de l’officialisation