Backed enums often need a plain list of their backing values, like ['active', 'inactive'], and many projects write their own values() helper for it. This RFC from Savin Mikhail adds a built-in values() method to every backed enum.

A GitHub search in November 2025 found about 7,460 hand-written versions of this helper. It also found about 2,900 traits that define values(), and each of those traits can be used by many enums.

Show me

Today you'd write something like this:

$values = array_column(Status::cases(), 'value');

With the RFC, you'd call the method directly:

enum Status: string {
    case Active = 'active';
    case Inactive = 'inactive';
    case Archived = 'archived';
}

var_dump(Status::values());
// ['active', 'inactive', 'archived']

The values come back in the same order as cases(), which is the order you declared them. The method only exists on backed enums, not on pure enums.

How it works

The method is added to the BackedEnum interface, and two design choices keep existing code from breaking:

  • Your own values() wins. PHP only adds the built-in version if the enum doesn't already have a values() method, including one from a trait.
  • No return type on the interface. Some existing helpers have no return type, or a different one, and adding : array would have broken them.

The trade-off is that values() becomes the only built-in enum method you can override. cases(), from() and tryFrom() are always native.

The RFC gives a few reasons to add it even though array_column() already works. It shows up in IDE autocomplete next to cases(), it gives libraries one standard method to call, and it makes the intent clearer at the call site.

What it means for existing code

Nothing breaks, since enums that already define values() keep their own version. IDEs, static analyzers and polyfills may need to update their stubs.

The RFC mentions a possible later step: a future PHP 8.x could deprecate user-defined values() methods, and PHP 9.0 could make them an error. That isn't part of this RFC.

Where it stands

The RFC is under discussion and targets PHP 8.6. The changelog says it was prepared for voting on January 18, 2026, but no vote has been held on the page. It will need a two-thirds majority to pass.