3 ms·

Unfortunately the chain approach breaks down when if you need to `map` to a different type, for example. Go does not allow generic typed methods.

• daghamm 2y ago
  I never understood why that limitation exist. Can someone explain the reason for this?
  • jerf 2y ago
    Straight from the designers: https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#no-parameterized-methods https://go.googlesource.com/proposal/+/refs/heads/master/des...
  • thefounder 2y ago
    https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#No-parameterized-methods https://go.googlesource.com/proposal/+/refs/heads/master/des...
  • mihaitodor 2y ago
    I recall reading some details around this on https://blog.merovius.de https://blog.merovius.de. Maybe it was this article: https://blog.merovius.de/posts/2018-06-03-why-doesnt-go-have-variance-in https://blog.merovius.de/posts/2018-06-03-why-doesnt-go-have.... Compilation speed plays a big factor when deciding which features are added to Golang and I think they'd have a hard time maintaining the current compilation speed if they remove this limitation.
  • mseepgood 2y ago
    https://go.dev/doc/faq#generic_methods https://go.dev/doc/faq#generic_methods
    • deleted 2y ago
      [deleted]
  • foldr 2y ago
    It's broadly similar to the reason why Rust won't allow generic methods on traits used to construct trait objects. It seems superficially like a reasonable thing to want, but actually isn't when you consider the details. (The sister comments link to the specific reasons why in the case of Go.)
  • tapirl 2y ago
    https://github.com/golang/go/issues/49085 https://github.com/golang/go/issues/49085
  • adonovan 2y ago
    It is a consequence of (a) Go's implicit relationship between a concrete type and the interfaces it implements and (b) Go's "heterogenous" translation of generics (like C++, unlike Java). Together, this means you can't know which methods you need a priori. All proposed solutions to date essentially compromise on (a) by limiting the generic "implements" relation to things known at build time, or on (b) by making generic methods "homegenous" (aka boxed) and thus slow (see https://github.com/golang/go/issues/49085#issuecomment-2316352221 https://github.com/golang/go/issues/49085#issuecomment-23163... for an elaboration of this approach); or, they involve dynamic code generation.
• simiones 2y ago
  You can actually (almost) make it work, you just need to add an extra type parameter to keep Go's silly limitations happy [0]: strs := []string{"abc", "defgh", "klmnopqrst"} ints := From[string, int](strs). Map(func(a string) int { return len(a) }). Filter(func(a int) bool { return a >= 4 }) Iterator[int, float32](ints). Map(func(a int) float32 { return float32(a) }). Each(func(a float32) { fmt.Printf("%v\n", a) }) //prints 5, then 10 If they allowed the postfix cast syntax to work for non-interface types too, it could have been a single chain, actually (you could do `.(Iterator[int, float32])` inline instead of needing the extra variable. Note that the original implementation in the article modifies the collections in place, in which case this issue doesn't come up at all: you can't put strings in an array of ints. My implementation creates copies of these collections so that the concept of mapping to a new type actually makes sense. [0] https://go.dev/play/p/ggWrokAk7nS https://go.dev/play/p/ggWrokAk7nS