Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129545
Precedence: list
MIME-Version: 1.0
Date: Thu, 04 Dec 2025 13:34:54 +0100
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Pattern Matching
In-Reply-To: <cef355bf-8066-4b06-a999-f313fbae5474@app.fastmail.com>
References: <e25ea0a6-bb82-4762-9e51-a543d0e6efe5@app.fastmail.com>
 <CAAwdEzDOd5v2UX4Ms8pn+73aSaVA1EMBr2n3c6RWztb5Fmanbg@mail.gmail.com>
 <cef355bf-8066-4b06-a999-f313fbae5474@app.fastmail.com>
Message-ID: <4e4b210a2b7156d6613b82a7e8ebd9b7@bastelstu.be>
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

Hi

Am 2025-12-02 21:06, schrieb Larry Garfield:
>> 2. Maybe some parts of the RFC could be separated to reduce 
>> complexity.
>> Thinking about variable pinning.
> 
> Actually, with the new implementation variable pinning turned out to be 
> stupidly easy.  That was a convenient bonus, which is why we included 
> it in the initial RFC.  It was originally in future scope, but the diff 
> to add it was like 10 lines or something, so we included it now.  The 
> future-scopes that are still in future-scope are all "harder than they 
> look" or "deciding what exactly to do will be a lot of discussion", 
> which is why they're there and not in the base release.

There are different dimensions to complexity. Your reply focuses on just 
“implementation complexity”, but there's also “documentation complexity” 
or “deciding-how-the-syntax-should-look complexity”. I feel that the 
syntax for “variable pinning” specifically has the weakest arguments in 
favor of it, with the main argument being “Ruby has it” rather than “it 
makes sense”. The other syntax choices either are “obviously correct” or 
have good arguments backing the choice.

Best regards
Tim Düsterhus