Maybe it's clearer if you simplify Wrap[A] to just Wrap, since they are
identical. https://go.dev/play/p/aJReo5lp2Yg
Then it's clear that the parameter "w Wrap" to func Extract is just a plain
old interface type, unrelated to generics. Dynamically at runtime it can
be nil, or a value of any type which implements the Wrap interface.
Interfaces aren't implemented by structural inheritance, they're just
duck-typing: "does the concrete type implement this method set?"
Therefore, these interfaces are identical and interchangeable:
type Wrap1 interface {
isWrap()
}
type Wrap2 interface {
isWrap()
}
type Wrap3[A any] interface {
isWrap()
}
You can pass a value of type Wrap2 to a function which expects type Wrap1.
https://go.dev/play/p/AabV-XGfj1g
On Tuesday, 21 June 2022 at 16:07:01 UTC+1 michel....@doctolib.com wrote:
> Hi,
>
> I'm not a generics expert either, but I think there is a misunderstanding
> here:
>
> The A in the Wrap[A any] is not the same as the A in Val[A any]. When you
> instantiate the Extract function with Extract[string], it expects a
> Wrap[string], which is, in fact, just a type implementing isWrap. The Val[A
> any] implements this method whatever the type it is instantiated with
> (string, int...) so Extract[string](Val[int]{3}) is, from my understanding,
> a completely valid expression. The only thing we can be certain of with
> this code is that the type switch will **not** reach the default case only
> precisely when the Val[A any] is instantiated with the same type as
> Extract[A any] function.
>
> Hope I'm not getting anything wrong :)
>
> On Tue, Jun 21, 2022 at 12:27 AM Tsvi Benschar <tsvihb...@gmail.com>
> wrote:
>
>> Hey everyone, reposting a question
>> <https://forum.golangbridge.org/t/generic-interface-compiles-with-incorrectly-instantiated-types/27809>
>> 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 <https://go.dev/play/p/UpEffRk8oB9> that
>> compiles. (Here's the correct version <https://go.dev/play/p/pE9AWb-xvda>.)
>> 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?
>>
>> --
>> 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/511571a9-044f-4a9b-8c5c-ed48c98206a5n%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/golang-nuts/511571a9-044f-4a9b-8c5c-ed48c98206a5n%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/1d4773ee-6ae9-445c-981f-b63358c35e6en%40googlegroups.com.
