On Thu, Jun 20, 2024, at 8:22 PM, Lynn wrote:
> On Thu, Jun 20, 2024 at 7:41 PM Larry Garfield <[email protected]> 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