On Thu, Jun 20, 2024 at 7:41 PM Larry Garfield <la...@garfieldtech.com> wrote:
> Hello, peoples. > > Ilija and I have been working on and off on an RFC for pattern matching > since the early work on Enumerations. A number of people have noticed and > said they're looking forward to it. > > It's definitely not going to make it into 8.4, but we are looking for > early feedback on scoping the RFC. In short, there's a whole bunch of > possible patterns that could be implemented, and some of them we already > have, but we want to get a sense of what scope the zeitgeist would want in > the "initial" RFC, which would be appropriate as secondary votes, and which > we should explicitly save-for-later. The goal is to not spend time on > particular patterns that will be contentious or not pass, and focus effort > on fleshing out and polishing those that do have a decent consensus. (And > thereby, we hope, avoiding an RFC failing because enough people dislike one > little part of it.) > > To that end, we're looking for *very high level* feedback on this RFC: > > https://wiki.php.net/rfc/pattern-matching > > By "very high level," I mean, please, do not sweat specific syntax details > right now. That's a distraction. What we're asking right now is "which of > these patterns should we spend time sweating specific syntax details on in > the coming weeks/months?" There will be ample time for detail bikeshedding > later, and we've identified a couple of areas where we know for certain > further syntax development will be needed because we both hate the current > syntax. :-) > > If you want to just read the Overview section for a survey of the possible > patterns and our current recommendations, you likely don't need to read the > rest of the RFC at this point. You can if you want, but again, please stay > high-level. Our goal at the moment is to get enough feedback to organize > the different options into three groups: > > 1. Part of the RFC. > 2. Secondary votes in the RFC. > 3. Future Scope. > > So we know where to focus our efforts to bring it to a proper discussion. > > Thank you all for your participation. > > -- > Larry Garfield > la...@garfieldtech.com I have been looking forward to this RFC, it's such a quality of life to be able to do all this! In terms of things to focus on, I'd personally be very happy with the property/param guards, "as" and "is <regex>", but I won't say no to anything we can get extra here because it's all really nice to have. I noticed that with array structure patterns the count is omitted when using ... ```php if ($list is [1, 3, ...]) { print "Yes"; } // True. Equivalent to: if (is_array($list) && array_key_exists(0, $list) && $list[0] === 1 && array_key_exists(1, $list) && $list[1] === 3 ) { print "Yes"; } ``` Wouldn't this need a `count($list) >= 2`? I'm not sure if the underlying mechanism does the count check as well, but it seems to me like a guard clause for performance reasons in the PHP variant. Maybe a tangent, what about iterators? "Limited expression pattern" I think this would be very valuable to have, though in the proposal it seems cumbersome to use regardless of syntax. It feels like I'm going to be using the variable binding less often than matching against other variables, what about an "out" equivalent? ```php $result = match ($p) is { Point{x: 3, y: 9, $z} => "x is 3, y is 9, z is $z", Point{$x, $y, $z} => "x is $x, y is $y, z is $z", }; // vs $x = 3; $y = 9; $result = match ($p) is { Point{x: 3, y: 9, out $z} => "x is 3, y is 9, z is $z", Point{$x, $y, out $z} => "x is 3, y is 9, z is $z", }; ``` To me this makes it much more readable, just not sure if this is even feasible. This is not meant as bikeshedding the syntax, more of an alternative approach to when to use which.
