> Most people who want sum types don't want the zero value to be nil. I am certainly one of those people, but, if interfaces with type lists can be used for sum types and generics constraints, it's well worth the trade off for keeping the language simple.
My major concern with the current notation is that it may make it too awkward to change later so type lists would be stuck as constraint-only. Even if better sum types that I'd be happier with are added later there would be overlap and footnotes. On Mon, Jun 22, 2020 at 3:45 PM Ian Lance Taylor <i...@golang.org> wrote: > > On Mon, Jun 22, 2020 at 3:03 PM jimmy frasche <soapboxcic...@gmail.com> wrote: > > > > Fair enough that I'd missed the last sentence. > > > > However, if you mark the types that require exact matches you can't > > reuse the same sigil in type assertion/switches, so it's unclear how > > those would work. > > > > Plus, it just seems backwards since exact is the default everywhere else. > > Yes, it's imperfect. We spent a few weeks looking for a good solution > here but couldn't find one, so we decided to push forward. We don't > want to optimize for sum types, since we're not at all sure that > interfaces with type lists are suitable for use as sum types. Most > people who want sum types don't want the zero value to be nil. > > Ian > > > > On Mon, Jun 22, 2020 at 2:40 PM Ian Lance Taylor <i...@golang.org> wrote: > > > > > > On Sat, Jun 20, 2020 at 3:51 PM jimmy frasche <soapboxcic...@gmail.com> > > > wrote: > > > > > > > > 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. > > > > > > https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#type-lists-in-interface-types > > > > > > Ian -- 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/CANG3jXLPX69%2BdQzhnCT78KVHmrCM8N%3DkEoV2o5pScWLLdN35bA%40mail.gmail.com.
