On Mon, 5 Nov 2018 at 11:38, Jamie Clarkson <jnc7...@gmail.com> wrote:
> Thanks Rog, yes that seems to be very similar to what I was converging on
> - I see you're combining the dictionaries per-implied-type (as I suggested
> above) into a single dictionary per generic function with one set of funcs
> for each instantiation. Makes sense.
>
> I've skimmed over your code but maybe you could explain something that I
> was pondering over the weekend: since the draft specifies that type
> parameters in types (e.g. a struct) will not be boxed how do you handle the
> differing offsets of members for any generic functions using them?
> (generating stub accessors or something?)
>
Yes. If generic code is able to access field members (personally I don't
think this is a good idea, but it's explicitly allowed by the contract
spec), then you could generate a stub function to return the value of the
field (or probably a pointer to it). It's tempting to think that we could
just store the field offset and use that, but that doesn't work for fields
in embedded pointer structs. There may well be a more
sophisticated-but-efficient approach, or you could just generate another
copy of the code, but using a stub accessor seems like it might work OK.
Basically, anything that involves doing more with the generic type than
just copying it around would require some kind of stub function.
cheers,
rog.
--
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.
For more options, visit https://groups.google.com/d/optout.
