Go generics draft design: building a hashtable

Re:Go generics draft design: building a hashtable by peter_l_downs on Wednesday June 17, 2020 @04:27PM (#23556320)

Take a look at the comment tree starting here in the Generics announcement thread from the other day for some discussion of Option[V] under the current proposal:

https://news.ycombinator.com/item?id=23545361

For what it worth, returning `(value, err)` is conceptually the same thing as returning a Result[V]. You can ignore the error case on a result / the None case on an option as easily as you ignore the `err` today.

[ Parent | on HN ]

Re:Go generics draft design: building a hashtable by MHordecki on Wednesday June 17, 2020 @04:44PM (#23556504)

> You can ignore the error case on a result / the None case on an option as easily as you ignore the `err` today.

The point of a result type is that you _cannot_ ignore the None case. Any method that would provide you with the value will also check that the error is not present.

In comparison, you can happily ignore `err` in Golang and continue with an invalid `value`.

[ Parent | on HN ]

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?

[ Parent | on HN ]

Re:Go generics draft design: building a hashtable by weberc2 on Wednesday June 17, 2020 @04:52PM (#23556594)

> In comparison, you can happily ignore `err` in Golang and continue with an invalid `value`.

I'm struggling to envision a Result type that requires you to be more explicit than `foo, _ := fallible()`. Seems like `fallible().Ok()` and similar are strictly less explicit.

[ Parent | on HN ]

Re:Go generics draft design: building a hashtable by hombre_fatal on Wednesday June 17, 2020 @05:10PM (#23556800)

To do anything with a Result/Optional, you have to explicitly get the value inside the box at some point. But the container abstraction also gives you a nice composition abstractions instead of the uncomposable top-level `val, err := do()` destructure.

Though perhaps not quite as compelling without real sum types. I'd have to play with Go's generic-typing sandbox more to form a stronger opinion.

[ Parent | on HN ]

Re:Go generics draft design: building a hashtable by kelnos on Thursday June 18, 2020 @03:40AM (#23560738)

> returning `(value, err)` is conceptually the same thing as returning a Result[V]. You can ignore the error case on a result / the None case on an option as easily as you ignore the `err` today.

No, you can't. If you want to pull the value out of a result and ignore errors, you have to explicitly do so. With `(value, err)` style error handling, you can write bugs by simply forgetting to check `err`.

[ Parent | on HN ]