Thanks Ian, I appreciate none of this has been implemented, just trying to understand the design space (including what the generated code will look like and how to get from the input contract definition & generic to the output code :) ). Also I realize that the compiler is free to do all sorts of tricks but hopefully some approximate idea of the output can be had.
Readers approximate solution: https://play.golang.org/p/QqvmvAj37Fc I'm not sure what you meant by conversion of non-interface to interface types to handle results? I can see the usual conversions working fine at the call site for input parameters but the actual ShortestPath func seems to need to use interface throughout? The graph example intrigues me the most because of the way the mutual recursion between the types needs to be handled in order to combine what in (some) other languages would be two explicitly mutual rec types into the single contract (and apparently implicitly mutual types). Jamie On Tuesday, October 30, 2018 at 1:50:02 PM UTC, Ian Lance Taylor wrote: > > On Tue, Oct 30, 2018 at 6:13 AM, Jamie Clarkson <jamie...@gmail.com > <javascript:>> wrote: > > > > Apologies if this is covered somewhere, have searched and not found. > > > > I'm curious about the Go2 generics draft, how does the team envisage the > > code generated for the ShortestPath (without code expansion like C++ > > templates where it's obvious)? I can come up with two so far. > > > > i) Use reflect to look up method names: > > > > So the basic generic ShortestPath would look a bit like: > > > > func ShortestPath(src,dst interface{}) interface{} { > > srcV := reflect.ValueOf(src) > > edgesM := srcV.MethodByName("Edges") > > edges := edgesM.Call(...) > > // etc. > > } > > > > ii) Autogenerate mutually recursive interfaces: > > > > type _N interface { > > Edges() []_E > > } > > > > type _E interface { > > Nodes() []_N > > } > > > > func ShortestPath(src,dst _N) []_N { > > edges := src.Edges() > > // etc. > > } > > > > I'm not considering the problems with either approach, like having to > wrap > > the actual concrete types or conversions of slice values. > > > > I'm also guessing I'm missing something obvious that makes it easy. > > None of this has been implemented, so it's impossible to be sure. > > That said, one approach is for the compiler to create implicit > interface types not only for Node and Edge but also for []Node and > []Edge. The implicit interface created for the slice types will > handle the slice indexing. The usual steps for conversion of > non-interface types to interface types will handle the method results. > Writing this out is left as an exercise for the reader. > > Ian > -- 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.
