2 ms·
By far the best option would be to add support for sum types and pattern matching. Besides being tremendously useful in its own right, it would also eliminate t
by wyager 5y ago
By far the best option would be to add support for sum types and pattern matching. Besides being tremendously useful in its own right, it would also eliminate the need for nulls.
- barrkel 5y agoI don't think that's right; absent data is really common and a desirable feature, and ergonomically handling it warrants built-in support. Outer joins inherently require a concept of absence of data, so you'd need a built-in Optional type which would be nullability in all but name. And you'd want lifting of operators on the inner type to the optional type for ergonomic reasons; doing a pattern match for every selection of bar.* where bar is left-joined would be extremely painful. I think you'd end up where you started on the null front. Sum types generally, for columns etc., maybe (pun not intended), but I'm skeptical about complex types in a relational language - structure ought to be represented as relations where possible so that everything else composes.
- wyager 5y agoIt would be ergonomic - you'd just use a variant of the equals operator specialized to Option<A> that behaved in the way you wanted.