> The closest you can go is this, but having an explicit rightward assignment:
>
> events.select { _1 => type:, role:; type == 'create' || role == 'admin' }
I'd actually recommend using in instead:
events.select { _1 in {type: 'create'} | {role: 'admin'} }
I really enjoy using in for filtering. But I get the OP's point.
Pattern matching does need QOL improvements to really feel like it's a first-class citizen of the language ... like patterning matching for method and block arguments. :)
I don't even use Ruby but I read this guy's articles every time they're posted. Always very thoughtful, it helps me organize some of my own thoughts on Python's syntax.
Thanks, that's the highest praise I could possibly hope for :)
It is one of the things I always enjoyed and tried to achieve myself (when the discussion of design decisions in one language would provide food for thought in the context of other languages/domains).
Thanks zverok. This helped me under stand pattern matching in Ruby better than any other articles I've read on the subject. I still don't really like it in Ruby (for some of the reasons pointed out in Irks And Quirks in this article) and don't think I'll be using it in my own Ruby programs (for now). But at least now I think I understand it well enough that I won't be totally confused when I see it show up in code. And I'll admit, I'm kind of intrigued by some possible use cases... specifically case-in seems like the way I'm most likely to one day use pattern matching.
