On Wednesday, 20 January 2021 at 11:53:23 UTC axel.wa...@googlemail.com wrote:
> Can you come up with a realistic reason to have that constraint that > doesn't end up needing reflect anyway (where you can implement any checks > you want)? > Mainly it's programmer comfort. If I write a container which holds a type T then: 1. I expect it to actually hold all values of the same type T, not a mixture of types A, B and C. 2. I expect it not to hold 'nil' values which have no concrete type at all If I was happy with the mixture of different types and/or nil values, then I could have just used an interface in the first place, not generics. I would get this comfort if interface types were *not* allowed to instantiate a generic type. It would then be up to the caller to "concretize" interface values into real values, which in turn would also force the caller to check they were not nil. However, it's all down to how the generic type is instantiated. I guess I can just ignore this, and assume nobody "abuses" my generic code by instantiating it with an interface type. As you said, this problem doesn't present for type lists, only for method interfaces. -- 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/6a2eedda-47ea-4ab8-ab85-66239e3ec3bbn%40googlegroups.com.
