I was more thinking about your Graph example which you posted where you're
using an item(type Node,Edge) struct {}, not accessing the members of the
Node and Edge types (which I agree is a dubious corner case) - looking at
it again though it looks like you're boxing with interface{} in the
generated code which is explicitly not allowed in the draft? Or am I
misreading it?
(I realise yours is a hypothetical implementation so not expected to be
complete! Just interested in what your preferred solution is)
Cheers,
Jamie
On Monday, November 5, 2018 at 12:41:02 PM UTC, rog wrote:
>
> On Mon, 5 Nov 2018 at 11:38, Jamie Clarkson <[email protected]
> <javascript:>> 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 [email protected].
For more options, visit https://groups.google.com/d/optout.
