Code change:
package transport <ins> // this is just to make the "unused" linter rule happy var _ = isCacheKeyComparable[tlsCacheKey] </ins> // assert at compile time that tlsCacheKey is comparable in a way that will never panic at runtime. <del> var _ = isComparable[tlsCacheKey] </del> <ins> // // Golang 1.20 introduced an exception to type constraints that allows comparable, but not // necessarily strictly comparable type arguments to satisfy the `comparable` type constraint, // thus allowing interfaces to fulfil the `comparable` constraint. // However, by definition, "A comparison of two interface values with identical // dynamic types causes a run-time panic if that type is not comparable". // // We want to make sure that comparing two `tlsCacheKey` elements won't cause a // runtime panic. In order to do that, we'll force the `tlsCacheKey` to be strictly // comparable, thus making it impossible for it to contain interfaces. // To assert strict comparability, we'll use another definition: "Type // parameters are comparable if they are strictly comparable". // Below, we first construct a type parameter from the `tlsCacheKey` type so that // we can then push this type parameter to a comparable check, thus checking these // are strictly comparable. // // Original suggestion from https://github.com/golang/go/issues/56548#issuecomment-1317673963 func isCacheKeyComparable[K tlsCacheKey]() { _ = isComparable[K] } </ins> func isComparable[T comparable]() {}

Related discussion:
text: Originally posted by in
/assign /triage accepted /sig api-machinery auth
/milestone v1.28
hi , v1.28 Bug Triage Lead here. Is this targeted to 1.28 release? If that is the case, can we probably set labels for easier tracking? Thanks!
hi again! Gentle reminder that the code freeze is starting (about 3 weeks from now), we want to ensure that each issue is dealt in timely manner and tracked. As the issue is tagged for 1.28, is it still planned for this release?
hi! I don't seem to find any PR being worked on to close this issue? Since it has not been updated for a long time, I'd like to check what's the status with you once again. FYI, as I informed about it already 2 weeks ago, we are in week 9 currently and the code freeze is starting next week (week 10) at . Please remove the milestone if this not currently tracked for v1.28 release or if it is still, please make sure that the fix is in before the code freeze date above, thanks!
/milestone next-candidate
/milestone v1.29
Hello ! Bug triage for the 1.29 release cycle is here! This issue hasn't been updated for a long time, so I wanted to check what the status is. The code freeze will start (), which is about 2 weeks from now. And while there is still plenty of time, we want to make sure that every PR has a chance to be merged on time. As the issue is tagged for 1.29, is it still planned for that release?
Hello ! Bug triage for the 1.29 release cycle is here! This issue hasn't been updated for a long time, so I wanted to check what the status is. The code freeze will start (), which is this week. We want to make sure that every PR has a chance to be merged on time. As the issue is tagged for 1.29, is it still planned for that release?
/milestone v1.30 kicking the can, we are way past code freeze
does this still target v1.30?
Hello! Release Signal shadow here. I'd like to check what's the status.