# [RFC] Deprecate Metaphone Function - Thread: https://externals.io/message/130691 - Original archive: https://news-web.php.net/php.internals/130691 - Started by 1372449351@qq.com on 2026-04-25T10:33:22+00:00 - Messages: 3 - RFC: Deprecate Metaphone Function (Withdrawn) — https://externals.io/rfc/deprecate-metaphone.md - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #130691 — 1372449351@qq.com — 2026-04-25T10:33:22+00:00 URL: https://externals.io/message/130691#130691 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> [1]: https://packagist.org/packages/voku/phonetic-algorithms [2]: https://packagist.org/packages/carloswph/linguistics [3]: https://packagist.org/packages/noodlesnz/double-metaphone --- ## #130806 — tim@bastelstu.be — 2026-05-08T07:49:17+00:00 URL: https://externals.io/message/130691#130806 · In reply to: #130691 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 --- ## #130807 — 1372449351@qq.com — 2026-05-08T08:26:10+00:00 URL: https://externals.io/message/130691#130807 · In reply to: #130806 Hi, >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. I am just aware of this RFC this morning when Gina told me about it.  Thankfully the RFC is still yet to move to voting process so it will be  more effective to withdraw this separate RFC and add a new entry in https://wiki.php.net/rfc/deprecations_php_8_6 >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  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. >implies and it's not a security-sensitive function where we would want  >to steer users towards safer 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