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
Hi,
Voting just opened on the "Single-Expression Functions" RFC.
Please find the following resources:
RFC: https://wiki.php.net/rfc/single-expression-functions https://wiki.php.net/rfc/single-expression-functions
Discussion: https://externals.io/message/127423 https://externals.io/message/127423
PR: https://github.com/php/php-src/pull/17677 https://github.com/php/php-src/pull/17677As 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
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
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
RFC: https://wiki.php.net/rfc/single-expression-functions
Discussion: https://externals.io/message/127423
PR: https://github.com/php/php-src/pull/17677
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:
https://externals.io/message/127423#127577
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
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