Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129186
Precedence: list
MIME-Version: 1.0
Date: Mon, 10 Nov 2025 07:40:43 +0300
Message-ID: <CAJYrtd_YrEnpSPjkQoQqFGVKOOf_sDgNf+=rtP=pxF1Bik4o2w@mail.gmail.com>
Subject: [PHP-DEV] [RFC] [Discussion] Add values() Method to BackedEnum
To: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000043b0106433623d0"
From: mikhail.d.savin@gmail.com (Mikhail Savin)

--000000000000043b0106433623d0
Content-Type: text/plain; charset="UTF-8"

Hi internals,

I've created an RFC to add a native values() method to BackedEnum:

https://wiki.php.net/rfc/add_values_method_to_backed_enum

== Summary ==

The RFC proposes adding BackedEnum::values() that returns an indexed array
of all backing values. The implementation uses conditional registration -
the native method is only added when the enum doesn't already define
values(), ensuring ZERO backward compatibility breaks.

Key points:
  * Native values() added automatically to new enums
  * Existing enums with custom values() continue working unchanged
  * Trait-based implementations are respected
  * Libraries can maintain their implementation for older PHP versions
  * Solves boilerplate problem (3,860+ implementations, ~24k-44k real usage)

Common use cases:
  * Database migrations: $table->enum('status', Status::values())
  * Form validation: in_array($input, Status::values())
  * API responses: ['allowed_values' => Status::values()]

== Implementation ==

Working implementation with conditional registration:
https://github.com/php/php-src/pull/20398

The engine checks if values() exists before registering the native version:
  - User-defined values() present? Use it.
  - No user-defined values()? Add native implementation.

== No BC Breaks ==

This approach ensures:
  * Existing code works unchanged (no migration needed)
  * Immediate benefit for new code (automatic values())
  * Gradual adoption possible (libraries can migrate at their pace)

Trade-off: Makes values() the only overridable enum method (unlike
cases/from/tryFrom). The RFC documents this as a pragmatic choice -
solving real problems without forced migrations.

== Questions ==

1. Is the conditional approach technically sound?
2. Is the API consistency trade-off acceptable given the zero BC breaks?
3. Any concerns with the implementation approach?
4. Should I implement some steps from "Future scope" of the rfc now?

Discussion period: 2 weeks minimum before voting.

Looking forward to your feedback!

Best regards,
Savin Mikhail

--000000000000043b0106433623d0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi internals,<br><br>I&#39;ve created an RFC to add a nati=
ve values() method to BackedEnum:<br><br><a href=3D"https://wiki.php.net/rf=
c/add_values_method_to_backed_enum">https://wiki.php.net/rfc/add_values_met=
hod_to_backed_enum</a><br><br>=3D=3D Summary =3D=3D<br><br>The RFC proposes=
 adding BackedEnum::values() that returns an indexed array <br>of all backi=
ng values. The implementation uses conditional registration - <br>the nativ=
e method is only added when the enum doesn&#39;t already define <br>values(=
), ensuring ZERO backward compatibility breaks.<br><br>Key points:<br>=C2=
=A0 * Native values() added automatically to new enums<br>=C2=A0 * Existing=
 enums with custom values() continue working unchanged<br>=C2=A0 * Trait-ba=
sed implementations are respected<br>=C2=A0 * Libraries can maintain their =
implementation for older PHP versions<br>=C2=A0 * Solves boilerplate proble=
m (3,860+ implementations, ~24k-44k real usage)<br><br>Common use cases:<br=
>=C2=A0 * Database migrations: $table-&gt;enum(&#39;status&#39;, Status::va=
lues())<br>=C2=A0 * Form validation: in_array($input, Status::values())<br>=
=C2=A0 * API responses: [&#39;allowed_values&#39; =3D&gt; Status::values()]=
<br><br>=3D=3D Implementation =3D=3D<br><br>Working implementation with con=
ditional registration: <br><a href=3D"https://github.com/php/php-src/pull/2=
0398">https://github.com/php/php-src/pull/20398</a><br><br>The engine check=
s if values() exists before registering the native version:<br>=C2=A0 - Use=
r-defined values() present? Use it.<br>=C2=A0 - No user-defined values()? A=
dd native implementation.<br><br>=3D=3D No BC Breaks =3D=3D<br><br>This app=
roach ensures:<br>=C2=A0 * Existing code works unchanged (no migration need=
ed)<br>=C2=A0 * Immediate benefit for new code (automatic values())<br>=C2=
=A0 * Gradual adoption possible (libraries can migrate at their pace)<br><b=
r>Trade-off: Makes values() the only overridable enum method (unlike <br>ca=
ses/from/tryFrom). The RFC documents this as a pragmatic choice - <br>solvi=
ng real problems without forced migrations.<br><br>=3D=3D Questions =3D=3D<=
br><br>1. Is the conditional approach technically sound?<br>2. Is the API c=
onsistency trade-off acceptable given the zero BC breaks?<br>3. Any concern=
s with the implementation approach?<div>4. Should I implement some steps fr=
om &quot;Future scope&quot; of the rfc now?=C2=A0<br><br>Discussion period:=
 2 weeks minimum before voting.<br><br>Looking forward to your feedback!<br=
><br>Best regards,<br>Savin Mikhail</div></div>

--000000000000043b0106433623d0--