4 ms·
It's far better than the previous drafts, another couple of drafts and it will be very good. I think that listing the possible types with "type" inside an inte
by _old_dude_ 6y ago
It's far better than the previous drafts, another couple of drafts and it will be very good.
I think that listing the possible types with "type" inside an interface is a mistake. It means that instead of providing builtin interfaces for existing primitive types, Go asks its users to list the primitive types in user defined interfaces. This will not go well if at some point in a future, the Go team want to add a new primitive type because the user codes will need to be upgraded.
And not providing inference when directly referencing a function is a weird choice (see section Type inference for generic function arguments).
- marcus_holmes 6y agoAgree. I think it'd be preferable to provide instances for existing primitives, even if those would need to be "special" to work (there's already "special" cases in the language for primitives, it's no biggy).
- yencabulator 6y agoThe problem with defining `numeric` somewhere, and programmer saying `interface I { numeric }` instead of `interface I { type uint8, uint16, blahblah }` is that the idea is to have exhaustive type switches for those: > This kind of type switch would only be permitted if the constraint lists explicit types, and only types listed in the constraint would be permitted as cases. So adding a new primitive type `uint128` to `numeric` would break all that code anyway: they would no longer be exhaustive type switches. Putting the programmer in charge means they can add support for `uint128` in the library at any time after the language change. I think type inference for generic function arguments is intentionally postponed to have a more reasonably-sized change going in first. It can be added later, making the explicit type parameter optional.