[VOTE] Single-Expression Functions

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

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