consistent powerful pattern matching everywhere?

[StefanKarpinski]

General pattern matching a la Magpie (discussion here) used for function dispatch, destructuring, switch case dispatch, and exception handling. See the brief email thread on the subject. We could still really use some pattern matching. The hardest part would likely be integrating it with multiple dispatch.

[JeffBezanson]

This is a throwaway issue. This needs a real proposal or some examples.

For functions, we would need to group patterns by type and convert the dynamic part (the part the type system doesn't model) to run-time checks:

f(x::2) = 0
f(x::3) = 1

becomes

f(x::Int32) = (x==2 ? 0 : (x==3 ? 1 : ... ))

This is really complex and makes it perhaps too easy to write overlapping or conflicting definitions. For example, you wouldn't implement +(x::Int,y::Int) = ... unless you really knew what you were doing, but it seems easier to write +(x::2, y::3) = 42. It's a silly example but you get the idea.

Another problem is that we don't have record literals, or structurally-typed records. So something like "name::String, age::Number" is not a type. As I said at one point, we could add records like this, which are basically tuples with named components. These are to keyword arguments exactly what tuples are to positional arguments, which has a certain elegance. But it just seems like too many features.

[StefanKarpinski]

These are the reasons why I made this a v2.0 issue and a speculative one. It's really just a placeholder for keeping the possibility in mind. Maybe we have a much more limited notion of pattern matching, but using the same approach for case statements and catch blocks seems sensible. We already have limited destructuring for tuples.

[si14]

+1 here :)

[friggeri]

I'd rather see something along the lines of :

f(2::Int) = 0
f(3::Int32) = 1

f(2) # -> 0
f(3::Int64) # -> no method f(3::Int64)

[JeffBezanson]

Yes that syntax makes more sense.

[JeffBezanson]

I don't think we need an issue to keep track of this idea.