On Mon, 6 Jul 2020 at 17:46, <tobias.l.gustafs...@gmail.com> wrote: > 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! >
I've also been playing around in this area. I've been trying something similar to this approach: https://go2goplay.golang.org/p/sHko_EMhJjA But this isn't ideal - note that we lose type safety when assigning back to the generic hash function, because there's no way to let the compiler know that the actual type of the generic type parameter is known at that point. I also noticed an interesting wrinkle to doing a type switch on a value of the type: We can't do this: case Hasher: hi = func(t Hasher) uintptr { return t } because the actual type probably isn't Hasher - it's the actual type, not the interface type. If a type switch on a type argument was implemented (and I definitely support it) we'd have to think carefully about what semantics would be desired in this case - if one of the types is an interface type, would one get the usual interface-subtype rules for matching or not? For the record, I quite like the idea of using a separate syntax for type-based checking: type switch T { case int: case string: } That way, we could use exact-match rules for that construct without risk of confusion with the normal type switch rules, and perhaps the difference might make it clearer that T would change its type inside the body of the switch. cheers, rog. > > 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 > <https://groups.google.com/d/msgid/golang-nuts/1e5a294f-ea3a-42a5-97ed-32471a2ed9a6o%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAJhgacgHKMoKNhoWs%3DF_LdpELVNsA3kT3UbXitxG4do%2B41FUPA%40mail.gmail.com.
