4 ms·
That's fair from one use, but the other, way more common in Go, is the whole "I'm going to return either an object OR an error". There's no common interface bet
by SmooL 6y ago
That's fair from one use, but the other, way more common in Go, is the whole "I'm going to return either an object OR an error". There's no common interface between the two, it's a distinct two options. Because go has no native support for sum types you get all this nonsense where every function returns a tuple of an object and an error, with the implicit assumption (not at all checked by the compiler) is that if the error is nil, then the object is valid. It's awful
- karmakaze 6y agoThat's not even true in the stdlid--there are some io errors that aren't errors per se and at the same time perform an action and return a value, e.g. short-write.
- reificator 6y agoSure, and in those cases you could continue to return a tuple. In fact having those cases not return a Result<T, E> when everything else does would actually make it more discoverable; right now people assume err means failure.
- AnimalMuppet 6y agoHmm. Instead of a sum type, it returns (in essence) a product type.
- SmooL 6y agoGood point; I guess that's really crux of the issue: we use it as a sum Type, but the compiler sees it only as a product Type