Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126277
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Mon, 03 Feb 2025 22:31:31 -0600
To: "php internals" <internals@lists.php.net>
Message-ID: <febe86f4-db37-4ea0-84ef-a30d59d832af@app.fastmail.com>
Subject: [PHP-DEV] Pattern matching details questions
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
From: larry@garfieldtech.com ("Larry Garfield")

Hi folks.  Ilija is still working on the implementation for the pattern matching RFC, which we want to complete before proposing it officially in case we run into implementation challenges.

Such as these, on which we'd like feedback on how to proceed.

## Object property patterns

Consider this code snippet:

class C {
    public $prop = 42 is Foo{};
}

The parser could interpret this in multiple ways:

* make a public property named $prop, with default value of "the result of `42 is Foo`" (which would be false), and then has an  empty (and therefore invalid) property hook block
* make a public property named $prop, with default value of "whatever the result of `42 is Foo {}`" (which would be false).

Since the parser doesn't allow for ambiguity, this is not workable.  Because PHP uses only an LL(1) parser, there's no way to "determine from context" which is intended, eg, by saying "well the hook block is empty so it must have been part of the pattern before it."

In practice, no one should be writing code like the above, as it's needlessly nonsensical (it's statically false in all cases), but the parser doesn't know that.

The only solution we've come up with is to not have object patterns, but have a property list pattern that can be compounded with a type pattern.  Eg:

$p is Point & {x: 5}

Instead of what we have now:

$p is Point{x: 5}

Ilija says this will resolve the parsing issue.  It would also make it possible to match `$p is {x: 5}`, which would not check the type of $p at all, just that it's an object with an $x property with value 5.  That is arguably a useful feature in some cases, but does make the common case (matching type and properties) considerably more clunky.

So, questions:

1. Would splitting the object pattern like that be acceptable?
2. Does someone have a really good alternate suggestion that wouldn't confuse the parser?

## Variable binding and pinning

Previously there was much discussion about the syntax we wanted for these features.  In particular, variable binding means "pull a sub-value out of the matched value to its own variable, if the pattern matches."  Variable pinning means "use some already-existing variable here to dynamically form the pattern."  Naturally, these cannot both just be a variable name on their own, as that would be confusing (both for users and the engine).

For example:

$b = '12';

if ($arr is ['a' => assign to $a, 'b' => assert is equal to $b]) {
    print $a;
}

Based on my research[1], the overwhelming majority of languages use a bare variable name to indicate variable binding.  Only one language, Ruby, has variable pinning, which it indicates with a ^ prefix.  Following Ruby's lead, as the RFC text does right now, would yield:

$b = '12';

if ($arr is ['a' => $a, 'b' => ^$b]) {
    print $a;
}

That approach would be most like other languages with pattern matching.

However, there is a concern that it wouldn't be self-evident to PHP devs, and the variable binding side should have the extra marker.  Ilija has suggested &, as that's what's used for references, which would result in:

$b = '12';

if ($arr is ['a' => &$a, 'b' => $b]) {
    print $a;
}

There are two concerns with this approach.

1. The & could get confusing with an AND conjunction, eg, `$value is int & &$x` (which is how you would bind $value to $x iff it is an integer).
2. In practice, binding is almost certainly going to be vastly more common than pinning, so it should likely have the shorter syntax.

There are of course other prefixes that could be used, such as `let` (introduces a new keyword, possibly confusing as it wouldn't imply scope restrictions like in other languages) or `var` (no new keyword, but could still be confusing and it's not obvious which side should get it), but ^ is probably the only single-character option.

So, question:

1. Are you OK with the current Ruby-inspired syntax?  ($a means bind, ^$b means pin.)
2. If not, have you a counter-proposal that would garner consensus?


Thanks all.

[1] https://github.com/Crell/php-rfcs/blob/master/pattern-matching/research.md

-- 
  Larry Garfield
  larry@garfieldtech.com