Sorry for accidentally sending the letter :( But I will continue the message.
In other words, all "mentions" of a variable, since they follow the "usual"
syntax of PHP, are expected to be the usages of these variables. On the
contrary: using them as variable-bindings would be error-prone. In the
example above, an existing variable $b would be silently overwritten by
whatever matched. So, from my point of view, "pinning" should be the
default behaviour.
As for the binding itself, I'm not really against it, but I personally don't
see much use of it, even if we come up with some dedicated syntax
for it. For example, if I match a variable against some pattern, I don't
really need to bind those values further, because they are very much
deterministic. What I mean is that in your proposal in general, we don't
have very complex patterns (compared to regexp, for example), to
remember the exact matched value. And also, it looks like it always
easy to obtain the needed value ad-hoc:
if ($p is Point(x: $x)) {
// We can always access $p->x
}
Variable binding would be most useful, as I've said, if we had complex
patterns and we don't know beforehand WHAT exactly matched. Like,
if we were searching for something which matches the pattern. For
example, if we "matched" an array against some pattern, and would
want to "capture" all the elements that did match. But as I understand
it, it is currently beyond the scope of current RFC.
My other concern is about object-matching. In your examples, you
give the following:
$e is Colorable(color: 'green', age: 4)&Example;
My belief is that such an approach - checking for a non-existent
property of a contract ("age") is kinda dirty. We should not allow
that. If we're checking specifically against a defined contract,
which does not have an $age property, we should not be able
to include this "property" in the pattern, and such pattern should
give a "property undefined" error.
Another concern about object-matching is positional matching
of properties. Same as above, to me it is kinda dirty. What I mean
is that if we're working with some "key" => "value" structure, the
exact position of the "key" in this structure must be irrelevant to us.
If we want to get $array['key'] or $object->property, we should never
rely on how exactly this key is "positioned" inside the data-structure.
On Sun, Jun 14, 2026 at 9:22 PM Alexander Egorov <[email protected]> wrote:
>
> Greetings! Thanks for the awesome RFC, I very much like the suggestion and
> would highly welcome it in general. But since the proposed update is
> really huge, I've got some concerns about some specific use-cases of it.
>
> My main concern is about variable binding / pinning. To me personally your
> current suggestion looks very counter-intuitive, which means that when I
> see a variable inside the patter, I would strongly expect it as a reference
> to an existing variable as part of the pattern:
>
> $b = 5;
> $a = 3;
> if ($a is $b) {...}
>
> Which translates to if $a === $b. Of course, same relates to more complex
> patterns.
>
> On Sun, Jun 14, 2026 at 9:08 PM Larry Garfield <[email protected]> wrote:
> >
> > Hi folks. Ilija and I would like to present our latest RFC endeavor,
> > pattern matching:
> >
> > https://wiki.php.net/rfc/pattern-matching
> >
> > You may note the date on the RFC is from 2020. Yes, we really have had
> > this one in-progress for 5 years. :-) (Though it was inactive for many of
> > those years, in fairness.) Pattern matching was intended as the next
> > follow up to Enums, as it's a stepping stone toward full ADT support.
> > However, we also feel it has enormous benefit on its own for simplifying
> > complex comparisons.
> >
> > This RFC has been through numerous iterations, including a full
> > implementation rewrite just recently that made a number of features much
> > easier. We have therefore included two patterns that were previously
> > slated for later inclusion but turned out to be trivially easy in the new
> > approach. (Variable pinning and numeric comparison.)
> >
> > Nonetheless, there are two outstanding questions on which we are looking
> > for feedback.
> >
> > Naturally given the timing, we will not be calling a vote until at least
> > late January, regardless of how the discussion goes. So, plenty of time to
> > express your support. :-)
> >
> > --
> > Larry Garfield
> > [email protected]
