Hi! I've spent some time lately to try out the go2go tool and the new generics proposal by converting a small hack I did some years ago for immutable data structures (https://github.com/tobgu/peds) which, in it's current shape, depends on code generation.
There is nothing really mind bending to this since it's a pretty mainstream collections case of generics and overall the conversion process was quite pleasant. So, good job on the generics proposal so far! I did run up against one issue though that I've not really been able to cope with in an elegant, and decently performant, way so far. That of providing different implementations depending on the underlying type. For my particular case I would like to use differnt hash functions for the map depending on the type of the map key. In addition to this I would also like the user of the library to be able to provide their own hash function, should they want to, by implementing a Hasher interface. I've provided some example code to illustrate what I would like to be able to do here: https://go2goplay.golang.org/p/HQcSZj_nfaF I've read the discussion in the draft on the limitations related to this here: https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#identifying-the-matched-predeclared-type But from that it's not entirly clear to me if: - This is a fix limitation that has been set to prevent bad design, unintended behaviour (compile time turing completness, language inconsistencies, etc.) or if it's a issue that should/will be fixed before the final implementation? - The limitations presented in the last paragraph of the above linked document are there for soundness of the implementation or if there are technical reasons for them? To me they seem unnecessarily restrictive. Since a type switch over a parametrized type could be evaluated at compile time it should be possible to use it in a fully type safe manner while it would provide the same type of flexibility at compile time that the current type switch provides at runtime. I'm also open to the fact that there may be entirely differnt ways to go about solving my particular problem (in a clean and efficient manner) within the bounds of the current spec. If so I'd be super happy to take suggestions! Thanks a lot! // Tobias -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/1e5a294f-ea3a-42a5-97ed-32471a2ed9a6o%40googlegroups.com.
