Hi,
Voting just opened on the “Single-Expression Functions” RFC.
Please find the following resources:
RFC: https://wiki.php.net/rfc/single-expression-functions
Discussion: https://externals.io/message/127423
PR: https://github.com/php/php-src/pull/17677
As with every RFC, a 2/3 majority is required.
Voting ends 2025-07-30 00:00:00 UTC.
Best regards,
Dmitrii Derepko.
@xepozz
On 15/07/2025 19:56, Dmitry Derepko wrote:
Hi,
Voting just opened on the "Single-Expression Functions" RFC.
Please find the following resources:
RFC: PHP: rfc:single-expression-functions
Discussion: RFC: Single-Expression functions - Externals
PR: feat: single expression functions by xepozz · Pull Request #17677 · php/php-src · GitHubAs with every RFC, a 2/3 majority is required.
Voting ends 2025-07-30 00:00:00 UTC.--
Best regards,
Dmitrii Derepko.
@xepozz
Hi
The voting widget seems missing, and the status seems not updated to "Voting".
Kind regards
Niels
Fixed.
You saved my life, thanks!
Best regards,
Dmitrii Derepko.
@xepozz
On Tuesday, 15 July 2025 at 19:28, Dmitry Derepko <xepozzd@gmail.com> wrote:
Fixed.
The voting widget is still marked as having the vote closed, and so it's impossible to vote on the RFC.
For future reference, you are allowed to vote on your own RFCs, doing so allows you to check that everything works before announcing the vote has started on the mailing.
Best regards,
Gina P. Banyard
On Tuesday, 15 July 2025 at 19:43, Gina P. Banyard <internals@gpb.moe> wrote:
For future reference, you are allowed to vote on your own RFCs, doing so allows you to check that everything works before announcing the vote has started on the mailing.
I forgot that you don't have voting karma, so please forget the second sentence of my prior email...
Best regards,
Gina P. Banyard
Hi
On 7/15/25 19:56, Dmitry Derepko wrote:
RFC: PHP: rfc:single-expression-functions
Discussion: RFC: Single-Expression functions - Externals
PR: feat: single expression functions by xepozz · Pull Request #17677 · php/php-src · GitHub
Thank you for the RFC. It probably does not come entirely unexpected that I voted against, given the feedback I provided during the discussion in:
I'd like to note that the start of the vote was very surprising to me. As you acknowledged yourself, my email regarding open questions and issues with the RFC has been left unanswered for more the a month and then you started voting 15 minutes after your response and making relevant changes to the RFC. This short of a time did not allow me (or other readers) to carefully consider the latest changes, which is the point of the discussion period.
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. 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.
Best regards
Tim Düsterhus
I'd like to note that the start of the vote was very surprising to me. As you acknowledged yourself, my email regarding open questions and issues with the RFC has been left unanswered for more the a month and then you started voting 15 minutes after your response and making relevant changes to the RFC. This short of a time did not allow me (or other readers) to carefully consider the latest changes, which is the point of the discussion period.
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.
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 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.
So please, use the RFC document to understand the intent and discussions to find already answered questions.
Anyway, I’m open for the news ideas, improvements and questions. Hope it will help you to change the opinion.
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
Hi, Internals!
Unfortunately, RFC didn’t pass the Voting stage:
18 people voted against, while only 6 voted for.
Thank you for your attention.
Best regards,
Dmitrii Derepko.
@xepozz