On Thu, Jun 20, 2024, at 5:38 PM, Larry Garfield wrote:
> To that end, we're looking for *very high level* feedback on this RFC:
>
> https://wiki.php.net/rfc/pattern-matching
Hi folks. Thank you to those who have offered feedback so far. Based on the discussion,
here's what we're thinking of doing (still subject to change, of course):
* We're going to move as to future-scope. There's enough weirdness around it
that is independent of pattern matching itself that it will likely require its own discussion and
RFC, and may or may not involve full pattern support.
* Similarly, we're going to hold off on the weak-mode flag. It sounds like the language needs
to do more to fix the definition of "weak mode" before it's really viable. :-( On
the plus side, if the type system itself ever adds support for a "coercion permitted"
flag, patterns should inherit that naturally, I think.
* Array-application will also be pushed to future-scope. Again, there's enough type-system tie
in here that is tangential to patterns that we'll pick that fight later.
* Ilija and I have discussed regex patterns a bit further, and it sounds like they’re going to be
rather complicated to implement. Even assuming we agree on the syntax for it, it would be a
substantial amount of code to support. (It’s not like types or literals or range where we can
just drop something pre-existing into a new function.) So we’re going to hold off on this one for
now, though it does seem like a high-priority follow-up for the future. (Which doesn’t have to be
us!)
So let's not discuss the above items further at this point.
* I'm going to do some additional research into other languages to see how they handle binding
vs using variables from scope, and what syntax markers they use and where. Once we have a better
sense of what is out there and is known to work, we can make a more informed plan for what we should
do in PHP. (Whether using a variable from scope in the pattern is part of the initial RFC is still
an open question, but we do need to design it alongside the capture part to ensure they don't
conflict.) Stay tuned on this front.
* We've removed the dedicated wildcard pattern, as it's equivalent to mixed.
If there's interest, we're open to having a secondary vote to bring it back as a
short-hand pattern. It's trivial to implement and we don't have strong feelings either
way.
* There's not been much discussion of range patterns. Anyone want to weigh in on those?
* The placement of is on match() is still an open question.
* No one has really weighed in on nested patterns for captured variables.. Any thoughts there?
* I’ve seen a suggestion for capturing the “rest” of an array when using … That’s an
interesting idea, and we’ll explore it, though it looks like it may have some interesting
implications that push it to future scope. It feels like a nice-to-have.
Thanks all.
--Larry Garfield