Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124531
Message-ID: <86eef5d8-6ffc-45e0-8ed6-6201a414cfb7@bastelstu.be>
Date: Sun, 21 Jul 2024 13:25:27 +0200
Precedence: bulk
MIME-Version: 1.0
Subject: Re: [PHP-DEV] Request for opinions: bug vs feature - change
 intokenization of yield from
To: Deleu <deleugyn@gmail.com>
Cc: Juliette Reinders Folmer <php-internals_nospam@adviesenzo.nl>,
 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>
 <CADK1yXK4bapqAWLZLNk--Fvo87AOv2qbSM1mTn23gU1JSMcL_g@mail.gmail.com>
Content-Language: en-US
In-Reply-To: <CADK1yXK4bapqAWLZLNk--Fvo87AOv2qbSM1mTn23gU1JSMcL_g@mail.gmail.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/20/24 20:14, Deleu wrote:
> Is there any evidence that PHP users are relying on code that:
> 
> - Was released just 7 months ago
> - Was not documented
> - Nobody knew about it until very recently

That is the wrong question to ask (see at the bottom).

> And furthermore, why should undocumented, unintentional, unapproved change
> to PHP be supported? Even if a handful of folks come to PHP's issue tracker

I do not see an issue supporting this from PHP's side. The issue was 
raised by a user of PHP, not by a PHP maintainer.

The change has also been explicitly acked by Gina and Christoph before 
Ilija committed it and Bob also participated in the PR without raising 
concerns, so it's also not an unapproved change. The fact that none of 
them anticipated this side effect, doesn't make it unapproved.

> to complain, the answer is plain and simple: that behavior was not approved
> by PHP's RFC process, which is the only way to get a behavior change
> introduced into the language. Realistically, it's highly questionable that

This is false. Small self-contained feature additions do not need to go 
through the RFC process. This is generally understood as "no one 
requests an RFC being written". The deadline for such a request is not 
defined as far as I know, but I believe it would be reasonable to assume 
that it implicitly is no later than the release of the PHP version in 
question, because otherwise any feature added this way would be at risk 
of arbitrary removal.

> such hypothetical users would even show up.
> 

I agree, but you can't say this for certain.

Weighting "breaking end user programs with a syntax error in a patch 
version" vs. "a power-user function emits unanticipated values in a 
field containing free-form data, but still follows its defined 
specification of emitting the token stream as PHP sees it", the former 
clearly has a much larger possible impact.

Best regards
Tim Düsterhus