I personally love pattern matching (one of the best features of Elixir and Erlang for my taste) and would be screaming in enjoyment if something similar would be introduced to Ruby but I'm kind of meh about the whole ordeal.
This is experimental. Even when we upgrade production systems to 2.7 I'm still going to refute usage of pattern matching in the code (and it still boggles my mind why add experimental feature to a public release of such mature language as Ruby) since there is no guarantee we won't have to rewrite everything back in 2.7.4 or 2.8
The other issue I'm having with it is that it is connected to a case statement. It might be just me, but I'd dream of having this in function header definition instead of a statement which I rarely see in code and am not too comfortable to use as well (this might be connected to the crowd I'm usually working with).
Kind of tangential but I really appreciate seeing this cross inspiration of Elixir and Ruby. Ruby taking inspiration from the pattern matching and pin operator of Elixir, and Elixir taking the initial direction from Ruby. I look forward to the future developments of both.
Refinements was also at some point marked as "experimental", and jruby maintainers have at some point declared not wanting to support it. It's 2020, refinements are still here, and jruby supports them, even with all its imperfections.
I'm wondering: how would you showcase an experimental feature to the community? Cuz if you're saying "3rd party library", there were already 3/ 4 different pattern matching libraries.
> how would you showcase an experimental feature to the community?
How do other languages do it? Python has the PEP process for discussing design on paper, but I don’t know how they handle experimental implementations.
The aim, from memory, is to gemify most of the standard library so why not release it as a "blessed" gem?
Edit: I see there is already the pattern-match gem [1], released as a proof of concept, although obviously it has slightly different syntax. Still, the reason why `case` is chosen (because `match` cannot be used) seems very thin.
Hmmm, I can kind of see it, but then you'd also need function overloading, right? With this you'd just do outer/inner functions, where the outer determines the pattern match and dispatches along to the appropriate inner function.
If you want to just make sure the function only accepts arguments that match a pattern, you're basically talking a guard pattern. Maybe a `return unless foo in <pattern>` syntax would then be nice (or some other one-liner), but it's not like it'd be hard to do it using this feature, you'd just use a few more mostly empty lines.
You mean that guards + destructuring would effectively be the same as pattern matching in function's params? Pattern matching would allow matching against more complex data structures more comfortably though.
The === operator is used by case statements, and can be used to implement pattern matching if you write objects which match in the way you want. It's how regexes match strings and ranges match numbers, etc.
What it doesn't have is destructuring combined with pattern matching, though it does have some destructuring assignments.
This is experimental. Even when we upgrade production systems to 2.7 I'm still going to refute usage of pattern matching in the code (and it still boggles my mind why add experimental feature to a public release of such mature language as Ruby) since there is no guarantee we won't have to rewrite everything back in 2.7.4 or 2.8
The other issue I'm having with it is that it is connected to a case statement. It might be just me, but I'd dream of having this in function header definition instead of a statement which I rarely see in code and am not too comfortable to use as well (this might be connected to the crowd I'm usually working with).