Per Ian's suggestion on the other thread I started (https://groups.google.com/g/golang-nuts/c/u9jqLPhEYO0/m/tnqezci8AwAJ), I'm breaking out this topic into a separate thread:
It seems strange to me that interfaces with type lists are really a different beast than regular interfaces, and aren't even meaningful as regular interfaces. (Trying to do that gives the error "interface type for variable cannot contain type constraints", which is relatively clear, at least.) As soon as an "interface" has a type list, it's not really a Go interface anymore (and interfaces with *only* type lists are not really interfaces at all, just type constraints). This seems confusing, though I'm not sure what the solution is. Ian noted that this is mentioned very briefly at https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#type-lists-in-interface-types but that he can't recall much discussion on this point. That section in the draft design notes starkly that "They may not be used as ordinary interface types." And then: "This restriction may be lifted in future language versions. An interface type with a type list may be useful as a form of sum type, albeit one that can have the value nil. Some alternative syntax would likely be required to match on identical types rather than on underlying types; perhaps type ==. For now, this is not permitted." That seems a little far-fetched to me, almost like a justification of what we know to be odd / confusing in this proposal. In terms of a "solution" for this, one that I'm sure has been thought about: what about keeping type constraints and interfaces completely separate? They are half the time anyway (when there are type lists), so why not make them separate all the time. I realize this may be heading back towards contracts (though without the funky syntax for operators). I think the "Featherweight Go" paper says "we don't need two different concepts here", but the paper doesn't seem to discuss "type lists" at all (and type lists seem very important to this proposal, and definitely are to this immediate discussion). Anyway, instead of saying "interface" you'd say "constraint": // this isn't really an interface, so don't call it one: type SignedInteger constraint { type int, int8, int16, int32, int64 } // this also can't be used as in interface, so don't call it one type ComparableHasher constraint { comparable Hash() uintptr } // yes, this duplicates the Stringer interface for use as a type constraint type Stringable constraint { String() string } I realize in the design draft the "Stringer" interface is used as a type constraint heavily, but that seems like a bit of an example/toy. In real-world code, how likely is it that we'll be using lots of existing interfaces as constraints? To me it seems like that won't be common, but I don't have much to go on. -Ben -- 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/CAL9jXCHa5%2B4LreE7acP_r3QEBMGKN6qzgzkLFv4VXsW5aoXfcw%40mail.gmail.com.
