You might already know of this since you mentioned pattern matching, but there is the `sealed` class modifier which allows for exhaustive matching on class subtypes. It's very limited: https://dart.dev/language/class-modifiers#sealed
I recall there being a reason unions aren't generally implemented, though I'm not sure where I read it. It was to do with union types being unnecessarily complex for the compiler and the code they tend to produce, at no real benefit to the programmer or the resulting program. Go's lack of unions is essentially based around the same reasoning.
It looks like it's an open discussion for Dart, but I can't see any explicit plans for an implementation.
It seems every language starts with free functions and classes (even mojo). They then realize that isn't so great: third parties are at a syntactic disadvantage (no dot fn's). And then, the language designers "fix" the problem with extension methods. Now you have three different function kinds, and we haven't even broached async.
Why not have only structs, free functions, and UFCS?
the historical expectation is that class methods will dispatch dynamically but free functions will not. so if you only have structs, functions, and UFCS you either:
1. don't dispatch on the first argument,
2. make the first argument privileged and dispatch on it, or
3. dispatch on all the arguments
the first solution is clean, but people really like dispatch.
the second makes calling functions in the function call syntax weird, because the first argument is privileged semantically but not syntactically.
the third makes calling functions in the method call syntax weird because the first argument is privileged syntactically but not semantically.
the closest things to this i can think of off the top of my head in remotely popular programming languages are: nim, lisp dialects, and julia.
nim navigates the dispatch conundrum by providing different ways to define free functions for different dispatch-ness. the tutorial gives a good overview: https://nim-lang.org/docs/tut2.html
so to sum up the answer to the original question: because it's only obvious how to make it nice and tidy like you're wanting if you sacrifice function dispatch, which is ubiquitous for good reason!
16 comments
[ 0.30 ms ] story [ 53.2 ms ] thread> This package exposes browser APIs. It's generated from the Web IDL definitions and uses recent Dart language features for zero-overhead bindings.
Dart doesn't get the respect it deserves.
For sure. Its only real use case is Flutter right now.
If Dart decided to expand things would get interesting.
That said, I really enjoy its focus on Flutter.
Lesser libraries, lesser IDE tooling, smaller community, no must have cases,...
Dart is evolving so quickly!
Also, any plans on union types? There is like no way to tell Dart when something can either by type A or type B.
I believe pattern matching is the only way at the moment.
I recall there being a reason unions aren't generally implemented, though I'm not sure where I read it. It was to do with union types being unnecessarily complex for the compiler and the code they tend to produce, at no real benefit to the programmer or the resulting program. Go's lack of unions is essentially based around the same reasoning.
It looks like it's an open discussion for Dart, but I can't see any explicit plans for an implementation.
Why not have only structs, free functions, and UFCS?
the first solution is clean, but people really like dispatch.
the second makes calling functions in the function call syntax weird, because the first argument is privileged semantically but not syntactically.
the third makes calling functions in the method call syntax weird because the first argument is privileged syntactically but not semantically.
the closest things to this i can think of off the top of my head in remotely popular programming languages are: nim, lisp dialects, and julia.
nim navigates the dispatch conundrum by providing different ways to define free functions for different dispatch-ness. the tutorial gives a good overview: https://nim-lang.org/docs/tut2.html
lisps of course lack UFCS.
see here for a discussion on the lack of UFCS in julia: https://github.com/JuliaLang/julia/issues/31779
so to sum up the answer to the original question: because it's only obvious how to make it nice and tidy like you're wanting if you sacrifice function dispatch, which is ubiquitous for good reason!