Replies: 2 comments 2 replies
-
I was playing around with the idea; maybe my branch is even still left over somewhere. The problem I remember was that we need to type assert a function (method) within a non-type asserted struct. And that is not possible. I don't remember exactly which struct it was, I think it was the Parser. Personally I want to release v5 "soon" and maybe focus on this in v6? |
Beta Was this translation helpful? Give feedback.
-
So I had another round of experiments (#271) and the result in a simple case is basically what your original example does. However, the problem is that in order for everything to work, I need to add type parameters to the This then leads to more ugliness, since I need to type parse token, err := jwt.ParseWithClaims(tokenString, &MyCustomClaims{}, func(token *jwt.Token[*MyCustomClaims]) (interface{}, error) {
return []byte("AllYourBase"), nil
}, jwt.WithLeeway[*MyCustomClaims](5*time.Second)) which is really ugly because there is just no way to justify that I need to specify my claims type to the leeway parser option :( |
Beta Was this translation helpful? Give feedback.
-
Hi,
I couldn't find this subject being discussed anywhere else. Sorry for the noise if I missed it!
Is there a consensus opinion on adding type parameter ("generics") support for v5? I'd like to be able to do something like the following without multiple type assertions:
My first naive approach working on the v5 branch doesn't feel very clean, so I wanted to gather some input putting more time into it.
Maybe if there are already plans to deprecate some options or change some more APIs for v5, this could become cleaner?
WDYT?
Beta Was this translation helpful? Give feedback.
All reactions