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
