4 ms·
>Comparable types (such as ordinary interfaces) may now satisfy comparable constraints, even if the type arguments are not strictly comparable (comparison may p
by subarctic 4y ago
>Comparable types (such as ordinary interfaces) may now satisfy comparable constraints, even if the type arguments are not strictly comparable (comparison may panic at runtime). This makes it possible to instantiate a type parameter constrained by comparable (e.g., a type parameter for a user-defined generic map key) with a non-strictly comparable type argument such as an interface type, or a composite type containing an interface type.
Wait, isn't that the whole point of the constraint in the first place, to keep you from using it with things that aren't comparable? Wouldn't it make more sense to have the constraint be a requirement in the interface itself, so that you can't create an interface value from a type that isn't comparable?
- subarctic 4y agoI mean, from my limited experience of Go, it's not exactly a language that tries to help you avoid unexpected runtime errors or anything, so maybe they figure Go programmers are already used to gotchas like that.
- 2h 4y agoWhy did you reply to yourself?
- AnimalMuppet 4y agoProbably didn't know about the "edit" button. I used to reply to myself before I learned about it. (And I still do, when the two-hour edit window has expired.)
- subarctic 4y agoWell actually, i think i did consider editing it, but it felt like my first comment stood fine on its own, and i'd leave the follow-up comment to be downvoted separately
- PoignardAzur 4y agoYeah, that edit window is way too short.
- tapirl 4y agoIt is really a pity Go didn't support the comparable interface from 1.0. The Go 1.20 change is just a compromise between theory perfection and the pity.