Re:Go generics draft design: building a hashtable
by peter_l_downs on Wednesday June 17, 2020 @06:19PM
(#23557485)
I see what you're saying, and while I think you're right, I think a lot more of the value is in being able to use `Map()` /`FlatMap()` to be able to avoid thinking about error checking at all, as I laid out in the second part of this comment https://news.ycombinator.com/item?id=23549396 . The convention of returning `(value, err)` goes a long way towards enforcing the checking of errors; I have golangci-lint's `errcheck` linter enabled and basically cannot accidentally ignore the `err` values. In any case, Option/Result types are extremely useful and I'm happy that with generics the language will be able to include them!
[ Parent
| on HN ]
Re:Go generics draft design: building a hashtable
by estebank on Wednesday June 17, 2020 @07:25PM
(#23558045)
For an ergonomic implementation of Result and Option you need to be able to represent tagged unions/enums/sum types, and having pattern matching makes dealing with them much more natural. These features are not planned for Go (yet?), right?