On Fri, 21 Aug 2020 at 23:03, Axel Wagner <axel.wagner...@googlemail.com> wrote:
> On Fri, Aug 21, 2020 at 11:46 PM Ian Lance Taylor <i...@golang.org> wrote: > >> Yes, there are various such possibilities. >> >> What jimmy frasche said above is correct: nothing changes in the case >> of a type switch of a type parameter. The code now knows the type >> list element that the type argument matched, but it can't do anything >> that it couldn't do anyhow. >> > > I think there are two reasonable things that it could be allowed to do in > the case, that aren't allowed outside: > 1. Convert to the matched type. We have a guarantee that the matched type > is either identical or has the same underlying type, both of which would > allow a conversion in the language as-is. I feel allowing this conversion > would be sufficiently useful (e.g. passing things to `strconv.Itoa` or > functions from `math` can be very useful). > Yes. Without this, I can't see that the type switch is useful for anything at all other than unsafe operations. 2. If the type is not a predeclared type, we could even take this a step > further, as the types must be identical - so we might allow treating them > as such. > This feels natural when viewed from the "type lists are essentially sum > types" POV. However, it would treat predeclared types more special than > other declared types and so it may be too elaborate to put into the spec. > It would also allow what rog suggest - but only in certain corner cases, > which feels weird. > > The more I think about it, the less I understand the intention behind the > type-switch construct introduced. I tend to agree that 1. at least should > be possible to make it useful. But even then, it seems like kind of a big > change for relatively limited use. What was the motivation behind that > change? Is there discussion somewhere, of interesting use-cases this > enables? > As one motivating example, imagine that we had some highly optimized machine code that sums a slice of 32 bit numbers, but we want to provide a generic version: https://go2goplay.golang.org/p/0YvkOcc-eBs I suspect that kind of scenario is one significant use case for using a type switch in a generic function, and I don't think that the type switch proposed is sufficient for that. -- 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/CAJhgacjn8dOOXU1%2BYZSM7nLDR4fqoCRHTJx3JRy20nN7fb44UA%40mail.gmail.com.
