[PHP-DEV] Suggest similar names for undefined function/method/class errors

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:

Kind regards,

Jorg

Hello Jorg,

On Tue, Aug 4, 2026, at 00:37, Jorg Sowa wrote:

“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, 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,

On Tue, Aug 4, 2026, at 00:37, Jorg Sowa wrote:

“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

On Thu, Aug 6, 2026, at 10:48 AM, Jorg Sowa wrote:

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