Skip to content

Conversation

@matthewmcneely
Copy link
Collaborator

Description

The Key generic constraint previously only accepted exact types (e.g., string, int), rejecting custom types like type UserID string even though they have valid underlying types.

  • Add ~ prefix to all types in Key constraint to accept types with matching underlying types
  • Add reflection fallback in KeyToHash to handle custom types at runtime (type switches only match exact types)
  • Add TestKeyToHashCustomTypes test

Fixes #400

Checklist

  • Code compiles correctly and linting passes locally
  • Tests added for new functionality, or regression tests for bug fixes added as applicable

Fixes #400

The Key generic constraint previously only accepted exact types (e.g.,
string, int), rejecting custom types like `type UserID string` even
though they have valid underlying types.

Changes:
- Add ~ prefix to all types in Key constraint to accept types with
  matching underlying types
- Add reflection fallback in KeyToHash to handle custom types at
  runtime (type switches only match exact types)
- Add TestKeyToHashCustomTypes regression test
@matthewmcneely matthewmcneely requested a review from a team as a code owner January 20, 2026 18:16
@matthewmcneely matthewmcneely merged commit 20299c0 into main Jan 21, 2026
5 checks passed
@matthewmcneely matthewmcneely deleted the matthewmcneely/update-type-constraint-to-support-typed branch January 21, 2026 21:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

[BUG]: Cannot use new type of string as z.Key param

1 participant