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