Maybe a ridiculous idea, but could we support the actual core pattern matching
syntax in some way to support this kind of thing? If so, it could make pattern
matching even more powerful than it already is.
This is *not* a good suggestion for the syntax I think its very very ugly and
not good,
Thanks for the reply, José. I was thinking that more ways to pattern match is a
good thing. I’m still new to the language so I might not have its philosophy
internalized yet.
I probably should have included at least the heads of the macros:
defmacro pattern_filter(value, pattern, default \\
Hi Matt, thanks for the proposal.
My concern with the proposal is that it introduces yet another way of
pattern matching, compared to case, =, and match?. Imagine I wrote this
code:
case res do
{:ok, value} -> value
:error -> :default
end
And if someone in a code review asked me to rewrite
Hi again. I’m new to this so apologies if I’m coming off as clueless or pushy.
I’m wondering what, if any, next steps there are to advocate for this. Should I
share the code? Given what I mentioned in the responses about using one
variable or using a new `destructure`, is there still
Hi Ben,
Thank you for the feedback!
The pattern_filter requires a pattern with exactly one variable and therefore
always returns just the value bound to that variable.
```
{1, 2, 3} |> pattern_filter({1, a, b})
```
would result in an ArgumentError, but
```
{1, 2, 3} |> pattern_filter({1, _a,
Apologies, I missed that you addressed how `{1, 2, 3} |> pattern_filter({1,
a, b})` would work in your earlier reply, in that you only allow a single
variable to be bound. This further reduces its general applicability.
On Thursday, December 15, 2022 at 4:12:37 PM UTC-5 Ben Wilson wrote:
> Hi
Hi Matt,
I am not on the core team nor do I speak for them. From what I have
generally seen, "alternative APIs" that can be implemented as libraries
generally should just stay libraries, unless there develops a strong
following that makes it clear that such an API should be moved into the
Hi Ben,
I agree that it reduces its applicability, but I see that as a virtue. Filter
and Map are useful despite being less applicable than Reduce, since they are
simpler.
Matt F
From: on behalf of Ben Wilson
Reply-To: "elixir-lang-core@googlegroups.com"
Date: Thursday, December 15, 2022
