On Tuesday, 29 December 2020 at 16:25:41 UTC [email protected] wrote:
> On Tue, Dec 29, 2020 at 4:37 PM Arnaud Delobelle <[email protected]> wrote: > >> Question 1: I *think* that the compiler has all the information necessary >> to implement type assertion to the Cont interface as I have, i.e. it knows >> only 3 types implement that interface, so could it not do the optimisation >> on my behalf? >> > >> > Question 2: Or is it possible that other Go values can be made at runtime >> that would implement this interface but not be one of the three known types >> that implement it? >> > > Yes, re 2. `reflect` can create new types at runtime. AFAIK the > implementation for interface-type-assertions is basically to look it up in > a global hashmap, which is pre-seeded with compile-time known types and > then gets filled on each (successful) inteface-type-assertion with the > correct method tables. But, I'm handwaving. > > Ok, I have just looked at the docs for the reflect package, but I can't see a way to create a type that implements anything but the empty interface. Is that correct? In that case, wouldn't it mean that it is known at compile time what types implement a given (non-empty) interface? Edit: I see that reflect.StructOf allows creation of struct types out of StructField specifications, which have an Anonymous boolean field. I imagine that the created struct will inherit the methods of embedded types, so it may implement non empty interfaces. I'm interested in valid use-cases for this, as it seems to be the thing that prevents this optimisation from being possible. Under these assumptions, it might be *possible* to first check against the > statically known types and only fall back on the map if none of that > matches. But it doesn't seem 100% clear to me that that's always faster. > > I think concrete type-assertions will always be faster than interface > type-assertions though - for a concrete type-assertions, it's really just > comparing the two type-pointers and copying the value (which, in your case, > is a pointer itself), whereas for an interface type-assertion, the actual > method table must be assembled or looked up. > Yes, that's what I was imagining, and why I decided to try coercion to concrete type instead! -- Arnaud -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/e6a8cd0f-bf8c-46ee-9435-48394a120cb5n%40googlegroups.com.
