One reason is that then your type can have a method like "Convert() T" where the actual type is not relevant (i.e. you do not need to actually have a generic type associated with it) but you can have a function that returns a specific type anyway. As methods can not have extra type parameters, this would be the only way to do something like that.
On Tue, Jun 21, 2022 at 10:38 AM Christoph Berger < christoph.g.ber...@gmail.com> wrote: > > The Wrap interface ignores its type parameter > > Curious, why doesn't the compiler consider this an error? I would expect a > "type parameter declared but not used" error, similar to the "variable > declared but not used" error. > Or are there valid use cases for types that declare a type parameter but > do not use it? > > > On Tuesday, June 21, 2022 at 12:49:10 AM UTC+2 Ian Lance Taylor wrote: > >> On Mon, Jun 20, 2022 at 3:27 PM Tsvi Benschar <tsvihb...@gmail.com> >> wrote: >> > >> > Hey everyone, reposting a question I asked on the go forum since it >> isn't getting replies there. I have some code that’s compiling and running >> despite there being a type error. I don’t understand go generics and >> interfaces that well, so I don’t know if this behavior is intended. >> > >> > Here's a simple incorrect program that compiles. (Here's the correct >> version.) On line 23 of the incorrect version, the function's generic >> parameter is instantiated to string, but its input is of type int. It >> compiles anyways and panics at runtime, even though the type switch's >> default case should never be reached. >> > >> > I got some similar examples to compile and run, they all involve >> instantiating a generic interface with one type but using it as if it had a >> different type. Is this behavior intended, or maybe is there some implicit >> unsafe cast happening? Or is this a bug? >> >> Thanks for providing a complete test case. >> >> The Wrap interface ignores its type parameter, so any type that >> implements a isWrap method with no arguments and no results will >> implement Wrap with any type argument. The argument to Extract is >> Wrap[A], so you can pass anything with an isWrap method to Extract. >> The type Val[int] does have an isWrap method, so it's fine to pass >> that type to Extract[int]. >> >> I don't understand what your code is trying to do, but the behavior >> seems entirely correct to me. >> >> 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/aa1f0a02-7fa3-414b-8be0-456e951cb439n%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/aa1f0a02-7fa3-414b-8be0-456e951cb439n%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/CAEd86TzYdUYZKo8cjVnZ8wtzqy%2BgOohzNT5jNJmnwLS%3D7wSMRQ%40mail.gmail.com.
