5 ms·

You'd need generics and algebraic types to implement Result/Option

• curun1r 9y ago
  False. That feature allows a more efficient implementation, but (T, error) (or an equivalent struct) can be reasoned about in much the same way as Result<T>. You don't need a tagged union when you can use the nil-ness of one of the two values in the tuple as the tag. Similarly, Option<T> is just a wrapper around a nullable T.
  • KirinDave 9y ago
    That would let people do this, and I hear people ask for it a lot. I dunno if it'd actually be better without the possiblity of not-wow-slow combinators. Golang has all these weird performance pitfalls that you only hit if you contort the language too hard. Naming combinatior functions sometimes trips those conditions. I'm of the opinion that even just pattern matching and the kind of nil type propagation checking that TypeScript does could help enourmously. Generics won't fix error handling without compiler help, and the best way to get that help is to introduce pattern matching as a forcing function.
  • leshow 9y ago
    The type you propose can inhabit both different variants at once, the entire point of Option is that it is either something or not.