From 0b3223b916c2034426ec9176d2a0738bbcf9d657 Mon Sep 17 00:00:00 2001 From: "M.V. Hutz" Date: Sat, 4 Jul 2026 20:01:34 -0400 Subject: [PATCH] docs: articulate core functionality --- docs/adr/001_design_principles.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/docs/adr/001_design_principles.md b/docs/adr/001_design_principles.md index cb782dd..530aac2 100644 --- a/docs/adr/001_design_principles.md +++ b/docs/adr/001_design_principles.md @@ -16,10 +16,11 @@ While the implementation does work, it lacks direction. To resolve this, I'm enforcing two new principles onto the contract of `go-cuckoo`: - **Congruency**: - A `go-cuckoo` table should have the same core functionality as Go's built-in map. + A `go-cuckoo` table should have the same core functionality as `map`. + By 'core', I mean `map`'s built-in syntax and functions (e.g. `range`, `m[k]`), and the `maps` package. - **Familiarity**: - A `go-cuckoo` table should behave similarly to Go's standard map, so users will intuitively know how to use it. + A `go-cuckoo` table should behave similarly to `map`, so users will intuitively know how to use it. In effect, its users will carry less cognitive load. These principles should _guide_ the public interface of `go-cuckoo`.