Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extensible pattern-matching #2949

Open
DartBot opened this issue May 8, 2012 · 13 comments
Open

Extensible pattern-matching #2949

DartBot opened this issue May 8, 2012 · 13 comments

Comments

@DartBot
Copy link

@DartBot DartBot commented May 8, 2012

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).

@DartBot

This comment has been minimized.

Copy link
Author

@DartBot DartBot commented May 8, 2012

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.

@gbracha

This comment has been minimized.

Copy link
Contributor

@gbracha gbracha commented May 8, 2012

We may act on this in the future.


Set owner to @gbracha.
Removed Type-Defect label.
Added Type-Enhancement, Accepted labels.

@anders-sandholm

This comment has been minimized.

Copy link
Contributor

@anders-sandholm anders-sandholm commented May 9, 2012

Added Area-Language label.

@gbracha

This comment has been minimized.

Copy link
Contributor

@gbracha gbracha commented May 24, 2012

Added this to the Later milestone.

@DartBot

This comment has been minimized.

Copy link
Author

@DartBot DartBot commented Jun 18, 2012

This comment was originally written by @seaneagan


issue #3722 proposes to have the "match" keyword above accept any Predicate defined as:

typedef bool Predicate<T>(T item);

@DartBot

This comment has been minimized.

Copy link
Author

@DartBot DartBot commented Jun 18, 2012

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 ...
}

@DartBot

This comment has been minimized.

Copy link
Author

@DartBot DartBot commented Apr 17, 2013

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;
};

@kasperl

This comment has been minimized.

Copy link
Contributor

@kasperl kasperl commented Jul 10, 2014

Removed this from the Later milestone.
Added Oldschool-Milestone-Later label.

@kasperl

This comment has been minimized.

Copy link
Contributor

@kasperl kasperl commented Aug 4, 2014

Removed Oldschool-Milestone-Later label.

@gbracha

This comment has been minimized.

Copy link
Contributor

@gbracha gbracha commented Dec 23, 2014

Issue #21847 has been merged into this issue.

@Aetet

This comment has been minimized.

Copy link

@Aetet Aetet commented Nov 6, 2016

Is matcher ready for daily use at regular code? Or it should be placed only at tests?

@lrhn

This comment has been minimized.

Copy link
Member

@lrhn lrhn commented Nov 7, 2016

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.

@lrhn lrhn added core-m and removed P2 labels Dec 6, 2018
@lrhn lrhn added this to Non-Breaking and Complex in Language Enhancement Categories Dec 14, 2018
@ghost

This comment has been minimized.

Copy link

@ghost ghost commented Jan 2, 2019

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*

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Language Enhancement Categories
Non-Breaking and Complex
7 participants
You can’t perform that action at this time.