Open jschaf opened 3 weeks ago
I'm getting a similar if not he same issue
go 1.23
require (
github.com/dgraph-io/badger/v3 v3.2103.5
github.com/dgraph-io/badger/v4 v4.3.1
)
# github.com/dgraph-io/badger/v3/table
../../../../../../vendor/github.com/dgraph-io/badger/v3/table/table.go:79:14: cannot use generic type ristretto.Cache[K z.Key, V any] without instantiation
../../../../../../vendor/github.com/dgraph-io/badger/v3/table/table.go:80:14: cannot use generic type ristretto.Cache[K z.Key, V any] without instantiation
Thank you for filling the issue. I am thinking that we can introduce another function such as NewCacheAnyK[K any, V any]
that requires that keyToHash
function is non nil and we take care of the rest. This will require some thought and some changes to the code. If you can create a PR, that'd be great. One of us can look into it as well when we can.
What version of Ristretto are you using?
v1.0.0
What version of Go are you using?
go version go1.23.1 darwin/arm64
Have you tried reproducing the issue with the latest release?
Yes
What is the hardware spec (RAM, CPU, OS)?
N/A
What steps will reproduce the bug?
Expected behavior and actual result.
Expected: Go should compile this code.
Actual:
Additional information
The type definition of
z.Key
only allows direct primitive types.Ideally, the generic constraint would allow new type wrappers over those already supported in the Key interface.
The rationale is to allow application code to use stronger types than
string
. This helps distinguish between string types likeUserID
andInvoiceID
.I suspect the problem with supporting new types is there's no way to detect the underlying type efficiently. You can't do it with a type-switch. However, when the user provides a
KeyToHash
function, we don't need the generic constraint.https://go.dev/play/p/fxOWPUemRz0
Proposal
any
.