You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
MyKey does not satisfy ristretto.Key (possibly missing ~ for string in ristretto.Key)
Additional information
The type definition of z.Key only allows direct primitive types.
package z
typeKeyinterface {
uint64|string| []byte|byte|int|int32|uint32|int64
}
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 like UserID and InvoiceID.
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.
When calling NewCache, check that either KeyToHash is provided or that the type is an implicitly supported key type. Then relax the Key constraint back to any.
The text was updated successfully, but these errors were encountered:
# 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
.The text was updated successfully, but these errors were encountered: