Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123742
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-522-ga39cca1d5-fm-20240610.002-ga39cca1d
Precedence: bulk
MIME-Version: 1.0
Message-ID: <be98ada8-a0a5-4c7a-8dc4-a3f6becf861a@app.fastmail.com>
In-Reply-To: <978b7177-8a22-41c0-94ce-d5539a2468c5@app.fastmail.com>
References: <2a6b92eb-d5e9-4a1a-9548-a068ac42ebd2@app.fastmail.com>
 <978b7177-8a22-41c0-94ce-d5539a2468c5@app.fastmail.com>
Date: Fri, 21 Jun 2024 18:29:19 +0000
To: "php internals" <internals@lists.php.net>
Subject: Re: [PHP-DEV] [Early Feedback] Pattern matching
Content-Type: text/plain
From: larry@garfieldtech.com ("Larry Garfield")

On Fri, Jun 21, 2024, at 12:38 PM, Rowan Tommins [IMSoP] wrote:
> On Thu, 20 Jun 2024, at 18:38, Larry Garfield 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.
>
> Hi Larry,
>
> I haven't time to read through the full RFC at the moment, but a couple 
> of thoughts:
>
> As Andreas says, we should be careful not to pre-empt things that might 
> be added to the type system in general, and end up with incompatible 
> syntax or semantics. That particularly applies to the generic-like 
> array<int> syntax, which is quite likely to end up in the language in 
> some form.

As noted in another thread, I don't believe that would cause any engine-level conflicts.  Whether it would cause human-level conflicts is another, and valid, question.

> The "weak-mode flag" seems useful at first glance, but unfortunately 
> PHP has multiple sets of coercion rules, and some are ... not great. 
> It's also not immediately obvious which contexts should actually 
> perform coercion, and which should just assert that it's *possible* 
> (e.g. match($foo) is { ~int => (int)$foo } feels redundant). So I think 
> that would need its own RFC to avoid being stuck with something 
> sub-optimal.

We *still* have different implicit coercion rules?  I assumed it would be implemented to match weak-mode parameters, not casting.  Though I agree, there are devils in the details on this one.

> Similarly, the "as" keyword has potential, but I'm not sure about the 
> naming, and whether it should be more than one feature. Asserting a 
> type, casting between types, and de-structuring a type are all 
> different use cases:
>
> $input = '123'; $id = $input as int; // looks like a cast, but actually 
> an assertion which will fail?
> $handler as SpecialHandler; // looks like an unused expression, but 
> actually an assertion?
> $position as [$x, $y]; // looks like its writing to $position, but 
> actually the same as [$x, $y] = $position?
>
> It's worth noting that in languages which statically track the type of 
> a variable, "$foo = $bar as SomeInterface" is actually a type of object 
> cast; but in PHP, it's the value that tracks the type, and interfaces 
> are "duck-typed", so it would be equivalent to "assert($bar is 
> SomeInterface); $foo = $bar;" which isn't quite the same thing.

Valid points.  The line between validation and casting is a bit squishy, as some casts can be forced (eg, string to int gives 0 sometimes), and others just cannot (casting to an object).  So would $a as array<~int> be casting, validating, or both?  Patterns make sense for validating, so it's natural to look to them for validate-and-cast.  Though I recognize it could then complicate the cast-only case, if it exists.

--Larry Garfield