I really like how the latest generics draft has progressed, fantastic work. The only thing that doesn't really feel perfect yet is type lists.
I like the idea of all constraints being interfaces and I get why interfaces with type lists and/or comparable are only constraints for now. I'd rather they be valid interfaces. For comparable that has a natural definition [1], but for type lists it's less obvious. [1] https://github.com/golang/go/issues/27481 If an interface with a type list is used as a sum type, it generally would want to restrict on exact type identity, just like a constraint generally does not want exact type identity. It would be strange if how the type list matched changed based on context. What if type lists could specify for each type whether it wants exact identity or the kind used in the draft? Since this is similar to the difference between type A B and type A = B I'll use type =X, Y to mean X is matched using the rules in the draft but Y must exactly match, so every example in the draft would need to be prefixed. Type assertions and switches could use this notation: type Str string var i interface{} = Str("x") s, ok := i.(=string) // ok is true, s is type string switch v.(type) { case =float32, =float64: case string: case =string: } (probably the = variety would only be for interfaces with type lists or perhaps only in generic code). It would be rare to want to use exact matches in interfaces as constraints and rare to use underlying matches in interfaces as values, but this would let both cases be handled uniformly yet distinctly. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CANG3jXKs_CPymGd0GnMw_g1COH%2Bkc-pJcqmkHWSG%2BEnqMp9VaA%40mail.gmail.com.
