On Thu, Jun 20, 2024, at 8:22 PM, Lynn wrote: > On Thu, Jun 20, 2024 at 7:41 PM Larry Garfield <la...@garfieldtech.com> wrote:
>> https://wiki.php.net/rfc/pattern-matching > 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. At the moment, the implementation doesn't actually compile down into those primitives; it has its own all-C implementation. Having it instead compile down to those operations is something Ilija is exploring to see how feasible it would be. (The main advantage being that the optimizer, JIT, etc. wouldn't have to do anything new to support optimizing patterns.) The examples shown in the RFC for now are just for logical equivalency to explain the functionality. In this case, the array_key_exists() checks are sufficient for what is actually being specified, so the count() is redundant. The final implementation will almost certainly be more performant than my example equivalencies. :-) > Maybe a tangent, what about iterators? Not supported, as you cannot examine them "all at once", by definition. I don't even know what an iterator-targeted pattern would look like, though if someone figured that out in the future there's no intrinsic reason such a pattern couldn't be added at that time. > "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. A couple of people have noted that. Assuming at least one of those two synaxes makes it into the initial RFC (I think variable binding has to for it to be really useful), we'll have a whole separate sub-discussion on that, I'm sure. Though, I would expect variable binding to be used more than expressions, not less, which would make the marker make more sense on the expression. But that's something to bikeshed later. --Larry Garfield
