While getting a bit carried away with my `castSwitch`(https://github.com/D-Programming-Language/phobos/pull/1266#issuecomment-53218941), I realized I can do more - much more - if I can create a "Constraint" struct, one that can limit the values it can receive based on it's template parameters, and that can be queried to verify if a value fits in those limits without relying on exceptions. That kind of struct will allow me mimic the concrete-values-in-pattern and the case guards that you can often see in (statically typed) functional languages.

Even with that function, I believe there is still room for the old `predSwitch`, `castSwitch` and `regexSwitch`:

`predSwitch`(https://github.com/D-Programming-Language/phobos/pull/1259) is a syntax optimization for when you don't care about the matched object, only which case matched.

`regexSwitch`(https://github.com/D-Programming-Language/phobos/pull/1392) provides simple string-to-value conversions and in the future will hopefully provide range-of-matches iteration(which will make it a mini-lexer)(the requirements for it to provide this are what currently block that PR, but that's OT).

`castSwitch`(https://github.com/D-Programming-Language/phobos/pull/1266#issuecomment-53218941) provides an optimization that skips many failed casts - that optimization takes up the majority of the code, and it will become so much more complex(and IMO infeasible) once we add the `Constraint` support, so I would rather leave it out of the super-powered pattern matching function and leave `castSwitch` as is.


So, after I finish adding multiple arguments support to `castSwitch` I want to start coding that full blown pattern matching function. Right now I consider two options:


1) First create the Constraint struct as a PR to `std.typecons` - that kind of struct might be useful for other things as well(think argument verification for reflective dispatch frameworks). After that gets accepted, create the monster pattern matching function as a PR to `std.algorithm`.

2) Create a third party library and make it available on DUB. Have that library closely follow the Phobos coding standards so someday we might add it as a new module.


The first option will allow it to get into the standard library faster, but the second will make it available faster and allow me to experiment more so I'm tending to choose it. If I follow that second path - do we have a convention for naming third party packages that aim to get into Phobos? Should I name it `stdx.patternmaching` or `std.experimental.patternmatching` or something?


Any opinions?

On 8/25/14, 2:30 PM, Idan Arye wrote:
> While getting a bit carried away with my
...................................
> Any opinions?

I have too much on my plate to look at this but I recall you had some really promising ideas and these seem to be in the same mold, so please continue, something great might come out of it. Good luck! -- Andrei

Don't have time to comment in details but wanted to warn about one thing : don't over-engineer. There is only limited value in a smart utility if its usage pattern can't be immediately recognized by a new developer.

On Monday, 25 August 2014 at 21:30:06 UTC, Idan Arye wrote:
> Any opinions?

Well, like the others, I unfortunately do not have time to look at this at the moment, but my first reaction is that it seems quite complicated, which would be a definite negative. So, I don't know how simple it can be to do what you're trying to do, but if it's complicated enough, then it probably won't get used, and it's more likely to be misused.

- Jonathan M Davis

On Monday, 25 August 2014 at 22:35:08 UTC, Dicebot wrote:
> Don't have time to comment in details but wanted to warn about one thing : don't over-engineer. There is only limited value in a smart utility if its usage pattern can't be immediately recognized by a new developer.

Well, what I had in mind is more complex than `predSwitch`/`castSwitch`/`regexSwitch`, but not *that* complex. I want to support syntax like:

uint multiplyTuple(Tuple(int, int) operands){
    return operands.patternMatch!(
        (Constrainted!(uint, "==", 0), uint _) => 0,
        (Constrainted!(uint, "==", 1), uint b) => b,
        (a, uint b) => b + multiplyTuple(tuple(a - 1, b)),
    )();
}