On Mon, Jul 6, 2020 at 9:46 AM <tobias.l.gustafs...@gmail.com> wrote: > > 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 for trying it out. I think that we haven't really figured out whether there should be a way to do a type switch on a type argument. It's not a technical limitation. We're just not sure what to do here. It sounds like you are in favor of supporting a type switch on a type argument. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVD5uPtNpGC7nKetTK3SX_P%2Be8PgxavchcZ31A%2BXL39FA%40mail.gmail.com.
