> > Even though all we did was save some references to values, the code has > radically changed (along with its runtime implications). >
Because I am lazy and simply trying to illustrate how this can be done. I was trying to achieve consensus, not to implement generics and I never pretended that you wouldn't have to put thought into the set of all functions needed. They are, however, definitely bounded above by ~60 - as reflect illustrates, you can implement any operation on any value with that. And FTR, that is an incredibly conservative upper bound, because you'd choose a suitable small subset based on the type-constructors used in the signature. Anyway. I'm officially giving up on that goal now. > The final code doesn't represent the original code well. For example, > using a callback function to emulate a range means that labelled > break/continue becomes harder to do, as do defer semantics etc. The addrS > function is taking the address of a slice inside that function, not the > address of the argument slice to sum. > > FWIW, here's your code written out slightly differently, with the > arguments put into an "instance" struct, and the save(sum(T)) call > included. This is similar to the style I've been been experimenting with > here > <https://github.com/rogpeppe/genericdemo/blob/master/graph/graph-generated-p-p.go> > > https://play.golang.org/p/GX2AbQNb8-a > > Note that we end up needing to generate an actual function stub with the > correct signature. That is, the compiler must generate this specifically > for each instance of the function. If it can do this, it could certainly > decide to generate inline code for it, which takes us right back to the > hill you decided to die on at the start of this thread, I think. :) > > -- 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.
