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. 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/CANG3jX%2BZuOxvOd%2BLzXLXVO1uVZvrwKmGiMZBBDDMebNNS0T%2Bxg%40mail.gmail.com.
