Based on Scala's pattern-matching with regular expressions syntax, I created the function std.regex.regexSwitch(formerly switchRegex). It's main use-case is for reading textual input fields that can be in multiple formats:
enum WeekDay
{
Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, Saturday
}
struct Schedule
{
WeekDay day;
int hour;
}
assert(equal(
[
Schedule(WeekDay.Sunday, 1),
Schedule(WeekDay.Monday, 14),
Schedule(WeekDay.Tuesday, 3),
Schedule(WeekDay.Wednesday, 4),
Schedule(WeekDay.Thursday, 17),
Schedule(WeekDay.Friday, 6),
],
[
"Sunday 1AM",
"Monday 2PM",
"Tuesday 3",
"4AM Wednesday",
"5PM Thursday",
"6 Friday",
].map!(regexSwitch!(
`(\w+) (\d+)AM`, (WeekDay day, int hour) => Schedule(day, hour % 12),
`(\w+) (\d+)PM`, (WeekDay day, int hour) => Schedule(day, hour % 12 + 12),
`(\w+) (\d+)`, (WeekDay day, int hour) => Schedule(day, hour),
`(\d+)AM (\w+)`, (int hour, WeekDay day) => Schedule(day, hour % 12),
`(\d+)PM (\w+)`, (int hour, WeekDay day) => Schedule(day, hour % 12 + 12),
`(\d+) (\w+)`, (int hour, WeekDay day) => Schedule(day, hour),
))()));
See https://github.com/D-Programming-Language/phobos/pull/1241
Comment #1 by bearophile_hugs — 2013-04-07T04:43:15Z
Another way to do this is with the unapply() of Issue 596
Comment #2 by GenericNPC — 2013-04-08T10:22:37Z
(In reply to comment #1)
> Another way to do this is with the unapply() of Issue 596
Yes, it looks like it is possible to do this with unapply(which should be opUnapply to be compatible with D's naming conventions). However:
1) In the GitHub pull request, Dmitry Olshansky suggests to combine all patterns to a single, big pattern, to improve performance. I have no idea how to do it, but it might be done in the future, and it can't be done with the switch+opUnapply version.
2) switch in D is a statement, not an expressions - it does not return a value.
3) Scala's unapply for regular expressions does not convert data types. I don't know if it can be done in D's version - it's too early to tell, seeing that opUnapply has not been implemented yet.
4) opUnapply is not in D yet - it's still an enhancement suggestion. We don't know what complications we are gonna have when we try to use it for regular expressions.
Comment #3 by dmitry.olsh — 2013-04-08T13:03:10Z
Only to add:
5) We can always add better abstraction if/when we are confident it's actualy better.
P.S. Doing minor correction - I'm reopening this untill the pull gets in. Let's do it pedantically in order ;)
@IdanArye
What we've unofficially all came to is a 3 step procedure:
1. Report
2. Pull posted there and keyword _pull_ is set.
3. Commits get posted automatically by post-commit hook, then somebody takes time to check and close it.
For the moment we are (sort of) at the stage 2.
(In reply to comment #3)
> Only to add:
> 5) We can always add better abstraction if/when we are confident it's actualy
> better.
>
> P.S. Doing minor correction - I'm reopening this untill the pull gets in. Let's
> do it pedantically in order ;)
>
> @IdanArye
>
> What we've unofficially all came to is a 3 step procedure:
> 1. Report
> 2. Pull posted there and keyword _pull_ is set.
> 3. Commits get posted automatically by post-commit hook, then somebody takes
> time to check and close it.
>
> For the moment we are (sort of) at the stage 2.
Oh, sorry. Had no idea about needing the `pull` keyword, or auto-closing when the request is pulled. My previous contribution to Phobos was done entirely on GitHub...
Just to be clear - the rule is still to use a single commit message for the contribution, using git's history rewriting functionality to make fixes, right?
Comment #6 by dmitry.olsh — 2013-04-08T13:33:32Z
(In reply to comment #5)
> (In reply to comment #3)
> > For the moment we are (sort of) at the stage 2.
>
> Oh, sorry. Had no idea about needing the `pull` keyword, or auto-closing when
> the request is pulled. My previous contribution to Phobos was done entirely on
> GitHub...
>
> Just to be clear - the rule is still to use a single commit message for the
> contribution, using git's history rewriting functionality to make fixes, right?
Yup, all the same. Plus this new idea of issue pre new stuff too.
I've seen cases where it the hook doesn't do closing. Could be a glitch or that an issue was mentioned but not as "fix issue xyz" but rather simply "issue xyz".
Comment #7 by GenericNPC — 2013-04-08T14:30:50Z
(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #3)
> > > For the moment we are (sort of) at the stage 2.
> >
> > Oh, sorry. Had no idea about needing the `pull` keyword, or auto-closing when
> > the request is pulled. My previous contribution to Phobos was done entirely on
> > GitHub...
> >
> > Just to be clear - the rule is still to use a single commit message for the
> > contribution, using git's history rewriting functionality to make fixes, right?
>
> Yup, all the same. Plus this new idea of issue pre new stuff too.
>
> I've seen cases where it the hook doesn't do closing. Could be a glitch or that
> an issue was mentioned but not as "fix issue xyz" but rather simply "issue
> xyz".
I used the GitHub syntax and wrote "fix #9895". I've changed it now to "fix issue 9895" to avoid problems...