Go generics draft design: building a hashtable

Re:Go generics draft design: building a hashtable by mseepgood on Wednesday June 17, 2020 @05:21PM (#23556934)

> We have function types literally at the same exression, but Go requires to repeat it.

It does not require it, the author chose to do it.

    t1 := hashtable.New(8, func(key string, m int) int {

is perfectly valid.

https://go2goplay.golang.org/p/SbEXpyVl-V3

[ Parent | on HN ]

Re:Go generics draft design: building a hashtable by mdlayher on Wednesday June 17, 2020 @05:46PM (#23557163)

In this particular case, the compiler can't infer the type of V if you omit the type parameters at the call sites:

  type checking failed for main
  prog.go2:17:3: cannot infer V (prog.go2:46:27)
  prog.go2:22:3: cannot infer V (prog.go2:46:27)

But generally you are right, yes. It is able to infer K at least.

[ Parent | on HN ]

Re:Go generics draft design: building a hashtable by galkk on Thursday June 18, 2020 @08:33PM (#23569737)

Thanks for noting, but my bigger concern was with different thing, that I’m also quoting from the doc (https://go2goplay.golang.org/p/LFo23rCKHXZ):

    func Filter(type T)(s []T, f func(T) bool) []T { ... }
 
    s:= []int{1,2m3}
    evens := slices.Filter(s, func(i int) bool { return i%2 == 0 })

The type of predicate is already in generic definition, we don’t need this verbosity. Other languages (I’d even say most of languages, used in dev work today) let us write simply something like slices.Filter(s, i->i%2).

[ Parent | on HN ]