3 ms·
Go 2 Error Values draft implementation – planned for v1.13
- networkimprov 8y agoIt has dropped the dependency on Go 2 Generics described in the "draft design". https://go.googlesource.com/proposal/+/master/design/go2draft-error-values-overview.md https://go.googlesource.com/proposal/+/master/design/go2draf...
- zelly 8y agoWow, looks like Go 2 might actually be usable.
- pstuart 8y agoGo 1 has been rather usable for many of us so far :-)
- ernst_klim 8y agoThey still suggest to return a pair of values on both error and non-error case and try to figure out, if your error value invalidates the main return value or not, instead of adding sum-types. Not to mention that error still does not signify statically its type. How is this useful? Why do go people try to reinvent the wheel for a problem long solved (with the result monad, exceptions, algebraic effects etc)?
- cyrusaf 8y agoSum types would add much needed compiler safety to returned errors and optional values. We often see nil pointer dereferences during runtime due to the usage of pointers as optional types.
- coldtea 8y ago>How is this useful? Why do go people try to reinvent the wheel for a problem long solved They think their designs are superior/simpler. Even when an approach's faults are acknowledged, they patch them with the same basic core logic (e.g. keeping arbitrary error signaling per function based on multiple return values), and add more accidental complexity.
- networkimprov 8y agoMultiple return values are useful in other ways; do you see them as a problem in general, or only error cases?