4 ms·
Each Unwrap() call needs two OK() calls? Letting Unwrap return OK would be better? BTW, the readability is really not good as Go 1.
by tapirl 5y ago
Each Unwrap() call needs two OK() calls? Letting Unwrap return OK would be better?
BTW, the readability is really not good as Go 1.
- SPBS 5y agoAs it rightfully should. God forbid people start returning Result[T] types instead of (T, error) and splintering the ecosystem. Option types are pointless if you don't have exhaustive pattern matching to ensure correctness.
- 4ad 5y agoGo's type system is actually expressive enough to ensure exhaustiveness, although it's non-obvious and syntactically heavy and impractical. I am working on a paper that will explore this.
- masklinn 5y ago> Each Unwrap() call needs two OK() calls? Letting Unwrap return OK would be better? That would rather miss the point as you'd be converting the type-safe result to an unsafe version? Go doesn't have pattern matching or any "structural" construct which would allow performing this in a single step, so the alternative would be to use HoFs and while Go has them they're quite verbose e.g. func (o Option[T]) Then(then func(T)) { if o.OK() { then(*o.value) } } a.Then(func (v int) { fmt.Printf("\tvalue = %d\n", v) }) which is… less than great. An safe other option would be a method mapping to a slice of 0..1 element and you'd use a `for range` as an `if` but that seems way to clever, similar to Scala's comprehensions over everything which I rather dislike. Also sadly the current proposal has no facilities for methods generic in their arguments independently from the subject, so no `Map` method.