Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124534
Message-ID: <f8bd2242-f821-41f5-b6c3-924e2c5aa0d5@bastelstu.be>
Date: Sun, 21 Jul 2024 13:48:32 +0200
Precedence: bulk
MIME-Version: 1.0
Subject: Re: [PHP-DEV] Request for opinions: bug vs feature - change
 intokenization of yield from
To: Larry Garfield <larry@garfieldtech.com>,
 php internals <internals@lists.php.net>
References: <66984FD0.5090805@adviesenzo.nl>
 <AM8P250MB0170FFCA0014FB9EC272DB4FE2AC2@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
 <c9736385-94b7-4064-911f-e5fc1df7e2bd@gmx.de>
 <AM8P250MB0170B4C59B4313A565CD029AE2AC2@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
 <6699F817.8070806@adviesenzo.nl>
 <9571bb82-9873-4319-9bd1-0361748335be@bastelstu.be>
 <669BDB00.70507@adviesenzo.nl>
 <fa7db246-1577-43b7-a117-c18a73140091@bastelstu.be>
 <669BE870.2050908@adviesenzo.nl>
 <b7b47e7a-fc20-4774-bc49-fff271386504@bastelstu.be>
 <86865df3-999e-4811-83de-eb35f7db167c@app.fastmail.com>
Content-Language: en-US
In-Reply-To: <86865df3-999e-4811-83de-eb35f7db167c@app.fastmail.com>
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

On 7/21/24 00:16, Larry Garfield wrote:
> Yes, any syntax change means tools need to adapt, but that doesn't mean tokenization can change randomly and accidentally.  Syntax changes require an RFC.  If an RFC passes that necessitates SA tools update, so be it.  (That happens almost every version.)  But that's still an RFC change.
> 
> I would agree with reverting this change for now.  The odds of it breaking something for someone are vanishingly small, and it's a bug, not a feature.  If we want it to be a feature, we can make an RFC for it.

It has become a feature no later than November, 23rd, 2023, when PHP 
8.3.0 has been released.

There is no bug, token_get_all() still is working within its specification.

We can't just break backwards compatibility with well-formed PHP scripts 
when it causes an inconvenience for tool authors and at the same time 
bend over backwards with an impact analysis to find out if the 
deprecation (not removal!) of a property that literally always is null 
would be too much of a backwards compatibility impact.

The PHP users writing PHP scripts accepted by PHP 8.3 and visually 
fitting into PHP’s syntax with regard to comment placement are not at 
fault here and shouldn't bear the consequences.

Best regards
Tim Düsterhus