On Mon, 5 Nov 2018 at 13:19, Jamie Clarkson <jnc7...@gmail.com> wrote:
> 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'm only boxing with interface{} in the generated code so I can use the
*item value as a map key (a real implementation would be able to create the
map with the underlying type's hash and equal functions).
The struct offsets fall out naturally from the fact that there would be a
different version of the code generated for each possible size/alignment of
the type parameters.
There's a naming convention in the code that I didn't explain. A generic
value is described by a string that implies its pointer map and alignment.
"p" represents a pointer; "v12" represents a run of 12 bytes; "a8" states
that the value requires 8 byte alignment (if there are any pointers in the
value, this is implied). So (assuming 64 bit architecture) "pp" describes
the layout of an interface value, "pv8" a string, "pv16" a slice, "v8a8" a
64 bit integer and so on. When a value has more than one type parameter,
these strings are separated with underscores. I wrote some code here
<https://github.com/rogpeppe/genericdemo/blob/master/generic/equiv.go#L147> to
calculate the string from an arbitrary type, although I don't have any code
that uses it currently.
Thus the type item__p_p represents all instances of the item type with two
pointer-like type parameters. So code that accesses fields within that type
within ShortestPath__p_p will use the correct offset, assuming
ShortestPath__p_p is actually instantiated with a type of the correct size.
Hope that helps.
rog.
Any identifier that matches the regexp '^.*_(_(p|v[0-9]+)+)(a[0-9]+)?$'
>
> (I realise yours is a hypothetical implementation so not expected to be
> complete! Just interested in what your preferred solution is)
>
Ah
>
> 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 <jnc...@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.
>
--
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.
