Everything

php

[RFC] Deprecate Metaphone Function

php.internals

=?utf-8?B?TGFtZW50WFU=?=

129 days ago

Hi internals,

Currently, PHP core maintains the oldest and least accurate version of the metaphone algorithm in C in the metaphone function. It was superseded by more accurate algorithms, namely Double Metaphone and Metaphone 3, and only limited to English pronunciation rules. There are already robust and actively maintained userland libraries available via Composer that implement Double Metaphone and Metaphone 3 [1][2][3].

I therefore would like to introduce a RFC to deprecate the metaphone function. Maintaining this legacy function in the core provides little value to modern PHP applications, and users could be advised to switch to more accurate alternatives. Even in the case where strict backward compatibility with core functions is preferred, people can still use soundex instead.

RFC link: https://wiki.php.net/rfc/deprecate-metaphone

I am happy to know your thoughts on this.

— Weilin Du <1372449351@qq.com, lamentxu@163.com&gt;

[1]: https://packagist.org/packages/voku/phonetic-algorithms
[2]: https://packagist.org/packages/carloswph/linguistics
[3]: https://packagist.org/packages/noodlesnz/double-metaphone

Tim Düsterhus

116 days ago

Hi

Am 2026-04-25 12:33, schrieb LamentXU:

> I therefore would like to introduce a RFC to deprecate the metaphone
> function. Maintaining this legacy function in the core provides little
> value to modern PHP applications, and users could be advised to switch
> to more accurate alternatives. Even in the case where strict backward
> compatibility with core functions is preferred, people can still use
> soundex instead.
>
> RFC link: https://wiki.php.net/rfc/deprecate-metaphone
>
> I am happy to know your thoughts on this.

I believe the deprecation of individual functions is better suited for
the bulk deprecation RFC at
https://wiki.php.net/rfc/deprecations_php_8_6, because there is often
not much to discuss and having individual RFCs for everything just adds
overhead.

That said: I don't think there is a strong argument in favor of
deprecating metaphone. Yes, the algorithm is dated. Yes, we likely would
not add this kind of functionality to the stdlib nowadays. But it's not
*actively* harmful as far as I can tell. It does exactly what the name
implies and it's not a security-sensitive function where we would want
to steer users towards safer options.

Best regards
Tim Düsterhus

=?utf-8?B?TGFtZW50WFU=?=

116 days ago

Hi,

&gt;I&nbsp;believe&nbsp;the&nbsp;deprecation&nbsp;of&nbsp;individual&nbsp;functions&nbsp;is&nbsp;better&nbsp;suited&nbsp;for&nbsp;
&gt;the&nbsp;bulk&nbsp;deprecation&nbsp;RFC&nbsp;at&nbsp;
&gt;https://wiki.php.net/rfc/deprecations_php_8_6,&nbsp;because&nbsp;there&nbsp;is&nbsp;often&nbsp;
&gt;not&nbsp;much&nbsp;to&nbsp;discuss&nbsp;and&nbsp;having&nbsp;individual&nbsp;RFCs&nbsp;for&nbsp;everything&nbsp;just&nbsp;adds&nbsp;
&gt;overhead.


I am just aware of this RFC this morning when Gina told me about it.&nbsp;
Thankfully the RFC is still yet to move to voting process so it will be&nbsp;
more effective to withdraw this separate RFC and add a new entry in
https://wiki.php.net/rfc/deprecations_php_8_6

&gt;That&nbsp;said:&nbsp;I&nbsp;don't&nbsp;think&nbsp;there&nbsp;is&nbsp;a&nbsp;strong&nbsp;argument&nbsp;in&nbsp;favor&nbsp;of&nbsp;
&gt;deprecating&nbsp;metaphone.&nbsp;Yes,&nbsp;the algorithm is&nbsp;dated.&nbsp;Yes,&nbsp;we&nbsp;likely&nbsp;would&nbsp;
&gt;not&nbsp;add&nbsp;this&nbsp;kind&nbsp;of&nbsp;functionality&nbsp;to&nbsp;the&nbsp;stdlib&nbsp;nowadays.&nbsp;But&nbsp;it's&nbsp;not&nbsp;
&gt;*actively*&nbsp;harmful&nbsp;as&nbsp;far&nbsp;as&nbsp;I&nbsp;can&nbsp;tell.&nbsp;
&gt;It&nbsp;does&nbsp;exactly&nbsp;what&nbsp;the&nbsp;name&nbsp;


AFAIK It doesn't. The metaphone algorithm is "dated" which means it is
way less accurate than other existing algorithms. That is, I don't think users
should be recommend to use it anymore. The core maintains the least
accurate version of metaphone.

&gt;implies&nbsp;and&nbsp;it's&nbsp;not&nbsp;a&nbsp;security-sensitive&nbsp;function&nbsp;where&nbsp;we&nbsp;would&nbsp;want&nbsp;
&gt;to&nbsp;steer&nbsp;users&nbsp;towards&nbsp;safer&nbsp;options.


Of course. However as I've said above it is not accurate. In other words,
it don't work well in today's cases comparing to user-land implementations.


Thanks, Weilin Du