Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128071
Message-ID: <a9d46608-96a2-4b5d-ae49-b6fa21b4372a@bastelstu.be>
Date: Wed, 16 Jul 2025 00:04:49 +0200
Precedence: bulk
MIME-Version: 1.0
Subject: Re: [PHP-DEV] [VOTE] Single-Expression Functions
To: Dmitry Derepko <xepozzd@gmail.com>
Cc: internals PHP <internals@lists.php.net>
References: <3cbe99a8-3415-45d3-aaf5-b5f921aab5e5@bastelstu.be>
 <D2FB3113-407C-44CF-8906-4536AF9000D5@gmail.com>
Content-Language: en-US
In-Reply-To: <D2FB3113-407C-44CF-8906-4536AF9000D5@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/15/25 23:37, Dmitry Derepko wrote:
> You’re right. I thought to shut down the RFC after absence of interest in the RFC, but Larry’s message reminded me that I should push it further to try to fit in the release cycle, which ends soon.

The latest date to start a vote for PHP 8.5 would've been 2025-07-29 
(i.e. two weeks from now). But even then, "trying to fit in the release 
cycle" should never be a reason to call a vote on an RFC where open 
issues and questions remain.

Once something is voted into the language it's effectively impossible to 
get rid of it or fix it, since that would result in a breaking change.

>> In fact the
>>
>>     $a = function() => 123;
>>
>> example that I mentioned in my email and that your response said wouldn't be allowed as part of the RFC still is in the existing proof-of-concept implementation.
>>
>> The RFC text itself also doesn't clearly specify what changes are proposed and instead just uses some handwavy language "This RFC introduces a shorthand syntax for functions that consist of a single return statement".
>>
>> In other words: It's not clear to me what changes to the language would happen, were this RFC accepted, since the RFC doesn't clearly specify it.
> 
> In the purpose I’ve mentioned the function types that are going to be changed in the RFC. I’m sorry if I made in unclear. Help me to improve it.

The vote on this RFC is already in progress, changing the RFC text other 
than to fix typos or other minor editorial errors is not okay, since 
that might invalidate any votes that have already been cast.

>> The implementation is not the source of truth (and contradicts your response anways), unless explicitly specified in the RFC together with a clearly specified revision.
> 
> As I understand the RFC process, the implementation means nothing unless the RFC accepted.

I wouldn't quite phrase it like this. The implementation does not need 
to be perfect, but it should certainly reflect what is actually being 
proposed in the RFC. As part of reviewing RFCs I'm also checking the 
implementation to find out (edge) cases where the RFC text could be 
improved to be more clear. Others are using the tests in the 
implementation as an additional source of examples.

> So please, use the RFC document to understand the intent and discussions to find already answered questions.

I've read the RFC and I feel that it doesn't adequately answer my 
questions. The most important part of an RFC is a precise definition of 
the proposed change, that is entirely missing from the RFC. The bulk of 
the RFC text is comparisons to existing syntax and examples. Providing a 
"user story" is something that should be in an RFC, but it's much less 
important than a precise definition of the proposal. Within the example 
section, it can also be helpful to include counter-examples which show 
error situations or something that is explicitly not part of the RFC.

> Anyway, I’m open for the news ideas, improvements and questions. Hope it will help you to change the opinion.

As outlined above, changing the RFC at this point is no longer possible. 
But even if the RFC text was clearer in what is actually being proposed, 
I'm reasonably positive that it would not change my mind regarding the 
cost/benefit ratio of the proposal.

Best regards
Tim Düsterhus