On Tue, Aug 18, 2020 at 8:29 PM Frederik Zipp <frederik.z...@gmail.com> wrote:
> The more I think about it the less I understand why type list should > reside inside interfaces. I can only think of two reasons: > > 1) Avoid a new keyword for type lists. > 2) The idea that only interfaces should be able to act as constraints. > I would argue it's neither, or both. The point is that we want a way to express constraints on type-parameters, allowing only certain types. We already have a way to express "any of a certain subset of types", which are interfaces, so using them for constraints is natural. They are also likely the most useful constraints - I would expect most Go users to *only* write pure-method interfaces and use the `constraints` package to write adaptor-functions for non-composite types. Meanwhile, we also want to be able to use operators, so there needs to be a way to fit that into the design and adding a new capability to interfaces is one such way. So, it's not 1, because it's not just about avoiding a new keyword, it's about avoiding a new *concept*. And it's not 2, because it's not really about *only* interfaces being usable as constraints, but definitely *also* (and probably at least primarily) interfaces being usable as constraints. FWIW, this topic has recently (and a couple of times before that) been discussed here: https://groups.google.com/g/golang-nuts/c/fCGL7iD8h2Q/m/hWELAQWcBQAJ Regarding 2): Why this artificial limitation? Why not allow all types as > constraints? Even int. It's nonsensical, but it would be like "interface{ > type int }" in the current draft, which is nonsensical, too. > No, it is neither the same, nor is it nonsensical. `interface{ type int }` is any type with *underlying type* `int`, not just `int`. It adds some expressive power. I'm not sure how important that expressive power is, but it's more than zero. Meanwhile, the natural meaning of using a concrete type *is* actually nonsensical. The rule would be simple: Any type can act both as normal type and as > constraint. With the possible exception of `anyof`s, until there is a > solution to use them as regular types as well. > > -- > 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/8711bcf9-6ebe-4014-9034-d0a642078791n%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/8711bcf9-6ebe-4014-9034-d0a642078791n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAEkBMfF0A%3DdeyVEJJqtABN_gapEcEbVtpPU6d4QcYKKywSYqkw%40mail.gmail.com.
