_This issue was originally filed by sammcca...@google.com_
It would be nice to match a value against patterns with a terse syntax.
This is similar to 'switch' (and could possibly share the same syntax) but instead of exact-match, the semantics would be determined by the pattern used.
When the pattern is a RegExp, it would match strings that conform to it.
A Type would match instances of that type.
User classes should be able to implement their own pattern behaviour.
Any value without special pattern behaviour would match using ==
for example:
switch (value) {
match Exception: throw value;
match const RegExp(@Â"\s+") return 'whitespace';
match 42: return 'the answer';
default: return 'unrecognized';
}
There was some discussion here: https://groups.google.com/a/dartlang.org/group/misc/browse_thread/thread/a3e75c24c6dd4f03/
A pattern might also be able provide values which can be bound to names (e.g. the Match object corresponding to a regexp match).
_This comment was originally written by sammcca...@google.com_
Hopefully this could also be unified with the pattern matching of exceptions in the 'catch' construct.
We may act on this in the future.
_Set owner to @gbracha._
_Removed Type-Defect label._
_Added Type-Enhancement, Accepted labels._
_Added Area-Language label._
_Added this to the Later milestone._
_This comment was originally written by @seaneagan_
issue dart-lang/sdk#3722 proposes to have the "match" keyword above accept any Predicate defined as:
typedef bool Predicate<T>(T item);
_This comment was originally written by @seaneagan_
Also, for type patterns currently we are stuck with doing "new isInstanceOf<int>" or "new isInstanceOf<BadNumberFormatException>". If types were first class and extended Predicate, then we could have:
switch(e) {
match(int) ...
match(String) ...
default ...
}
and similarly for catch statements:
catch(e) {
match(NullPointerException) ...
match(BadNumberFormatException) ...
default ...
}
_This comment was originally written by @tomochikahara_
I think Enum pattern matching in Haxe is easy to add to Dart with enum.
enum Card { number(num n), jack, queen, king, joker }
num toNumber(Card card) => switch(card) {
case number(n): n;
case jack: 11;
case queen: 12;
case king: 12;
case _ : -1;
};
_Removed this from the Later milestone._
_Added Oldschool-Milestone-Later label._
_Removed Oldschool-Milestone-Later label._
Issue dart-lang/sdk#21847 has been merged into this issue.
Is matcher ready for daily use at regular code? Or it should be placed only at tests?
The matcher class is definitely well tested, but it's built for testing, not performance. I don't think it'll make a good substitute for language-level pattern matching.
That could be more beautiful
switch (value) {
on Exception: throw value;
on const RegExp(@Â"\s+") return 'whitespace';
on 42: return 'the answer';
otherwise: return 'unrecognized';
}
And to make it possible you can use Unification*
Why not pattern matching in Haskell/Erlang Style, on the function arguments ?
I like the Java or Scala style.
@hepin1989 , so you prefer to solve, let's say the problem n. 1 (of the 99 problems like:
<T> T f1(List<T> list) {
if (list.isEmpty()) throw new NoSuchElementException("List is empty");
List<T> elements = list.tail();
List<T> result = list;
while (elements.nonEmpty()) {
result = elements;
elements = elements.tail();
}
return result.head();
}
instead of:
f1 :: [a] -> a
f1 [x] = x
f1 (_:xs) = f1 xs
:)
@leafpetersen @munificent @lrhn – should this be in the language repo?
https://github.com/dart-lang/language/issues/1047#issuecomment-646088104 @henry-hz your first example is too long and your second is too hard to read, it's too different from what most people know. Typing less caracter doesn't make it easier.
What about the Kotlin style ?
fun f1(list: List): List = when(list) {
list.isEmpty() -> throw Stuff
list.tail().isEmpty() -> list.head()
else -> f1(list.tail())
}
(it may contain errors, i'm on mobile and don't do Kotlin often)
You have to type more than your second example, but i think any programmer can understand this piece of code, unlike yours.
Most helpful comment
That could be more beautiful
And to make it possible you can use Unification*