> One reason is that then your type can have a method like "Convert() T"
But then the type parameter is not unused anymore. On Tuesday, June 21, 2022 at 8:14:51 PM UTC+2 b...@gmail.com wrote: > 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...@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...@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/980e448a-564e-4950-ad40-19f5d3a80437n%40googlegroups.com.
