Hello internals,
Would this change be acceptable to merge without an RFC?
https://github.com/php/php-src/pull/22589
It adds “did you mean …?” suggestions to errors for undefined functions.
While it does not change language semantics, it changes error messages and
introduces additional checks on error paths, so I would like to confirm
whether consensus on the PR is sufficient or an RFC is expected.
If the sentiment is positive, I would like to pursue this direction for
methods, classes, constants etc.
Similar approach is used in Python or Ruby already:
-
Python: https://docs.python.org/3/whatsnew/3.10.html#nameerrors
-
Ruby: https://docs.ruby-lang.org/en/3.3/DidYouMean.html
Kind regards,
Jorg
Hello Jorg,
“did you mean …?” suggestions to errors for undefined functions. While it does not change language semantics, it changes error messages and introduces additional checks on error paths, so I would like to confirm whether consensus on the PR is sufficient or an RFC is expected.
Thanks, this is great.
According to PHP Policy RFC: Exempt input type and value validation from BC Break policy https://wiki.php.net/rfc/policy-exempt-type-value-error-bc-policy, rephrasing error messages is not subject to the backwards compatibility break policy.
I think the amount of punctuation at the end is a bit much. Perhaps it would be clearer (although less strictly correct) to say "(did you mean func?)" instead of "(did you mean func()?)". But either way I am in favor of this.
Regards,
Sjoerd Langkemper
Hi,
Il 04/08/2026 09:55, Sjoerd Langkemper ha scritto:
Hello Jorg,
“did you mean …?” suggestions to errors for undefined functions. While
it does not change language semantics, it changes error messages and
introduces additional checks on error paths, so I would like to
confirm whether consensus on the PR is sufficient or an RFC is expected.Thanks, this is great.
According to PHP Policy RFC: Exempt input type and value validation from
BC Break policy <https://wiki.php.net/rfc/policy-exempt-type-value-
error-bc-policy>, rephrasing error messages is not subject to the
backwards compatibility break policy.
We are very close to the soft feature freeze. I'm looking forward to
hearing some feedback on the list.
I think the amount of punctuation at the end is a bit much. Perhaps it
would be clearer (although less strictly correct) to say "(did you mean
func?)" instead of "(did you mean func()?)". But either way I am in
favor of this.
I do agree here there's a bit too much punctuation. Perhaps something
similar to what Python does (according to the posted link)?
Call to undefined function defined(). Did you mean: define?
Cheers
Matteo Beccati
Thank you both for the opinions. I think it will be reasonable to not rush
for PHP 8.6. I found few nuances that I would like to consider properly. I
will finish it after feature freeze.
I do agree here there's a bit too much punctuation. Perhaps something
similar to what Python does (according to the posted link)?
Call to undefined function
defined(). Did you mean: define?
I have hard time choosing best option. Python and Ruby don't have file and
line number at the end of error message and question mark looks good in
such setup. I don't want change the error structure to put the suggestion
part at the end of error message. But otherwise in all cases I think of, it
looks ugly.
Kind regards,
Jorg
Thank you both for the opinions. I think it will be reasonable to not
rush for PHP 8.6. I found few nuances that I would like to consider
properly. I will finish it after feature freeze.I do agree here there's a bit too much punctuation. Perhaps something
similar to what Python does (according to the posted link)?Call to undefined function
defined(). Did you mean: define?I have hard time choosing best option. Python and Ruby don't have file
and line number at the end of error message and question mark looks
good in such setup. I don't want change the error structure to put the
suggestion part at the end of error message. But otherwise in all cases
I think of, it looks ugly.Kind regards,
Jorg
I'm in favor of this improvement, but I agree it's best to not rush it. If it doesn't happen until 2027, that's OK. I also don't have especially strong opinions on the precise wording, so will largely leave that to those who do care.
I don't think an RFC is needed here, but if we decide to have one, I'd recommend it be an abstract "we should use this pattern for error messages" type RFC, not one that deals with specific examples. Keep it flexible.
--Larry Garfield