3 ms·
I just want Result types I can map over. That would cut out a bunch of clutter. Even if I could pair one fallible function with one infallible function, that's
by kortex 5y ago
I just want Result types I can map over. That would cut out a bunch of clutter. Even if I could pair one fallible function with one infallible function, that's 50% less err != nil
val, err := int_or_err(foo)
if err != nil { return nil, err}
return val.add(bar), nil
Vs
result := int_or_err(foo)
return val.map(add,bar)
I'd even take some sort of
result := int_or_err(foo)
return val.map(add,bar).tuple()
to return a val,err pair in order to match conventional go.
- Cthulhu_ 5y agoIt looks more concise but if you're like me not into functional programming much, .map() is magic. Consistency is more important than conciseness. Clear is better than clever. Plus, a function invocation / .map() is heavier than an err != nil check / condition. Don't get me wrong, I appreciate the Either pattern as an alternative to if err != nil, but I also appreciate the really dumb and straightforward approach of non-clever Go.