On Thu, 6 Nov 2025 at 05:35, Marc B. <[email protected]> wrote: > > Hi Savin, > > Thanks for sharing your idea. > > On 06.11.25 05:09, Mikhail Savin wrote: > > Hi internals, > > > > I would like to propose adding a native values() method to the BackedEnum > > interface that returns an array of all backing values. Before creating a > > formal RFC, I'm seeking feedback on the concept and approach. > > > > == Summary == > > > > The proposal adds: > > > > interface BackedEnum { > > public static function values(): array; > > } > > > > This would allow: > > > > enum Status: string { > > case Active = 'active'; > > case Inactive = 'inactive'; > > } > > > > Status::values(); // ['active', 'inactive'] > > > > == Motivation == > > > > This pattern is extremely common in the wild. Based on GitHub code search: > > > > * ~3,860+ direct implementations of this exact pattern > > * ~20,000-40,000 estimated real usage when accounting for shared traits > > * Used in major frameworks: Symfony core (TypeIdentifier.php), > > Laravel ecosystem > > * Documented by PHP.net: The manual itself shows EnumValuesTrait as > > an example > > > > Common use cases: > > * Database migrations: $table->enum('status', Status::values()) > > * Form validation: $validator->rule('status', 'in', Status::values()) > > * API responses: ['allowed_statuses' => Status::values()] > > I agree, this is a common feature I would like as well. > > > > > == Backward Compatibility - Important Discussion Point == > > > > This is a breaking change. Enums that already define a values() method > > will fail with: > > > > Fatal error: Cannot redeclare BackedEnum::values() > > > > Based on ecosystem research: > > * ~24,000-44,000 enum instances will break > > * All implementations are functionally identical to what's being > > proposed > > * Migration is mechanical: just delete the user-defined method > > > > The break is justified because: > > > > 1. Behavior is unchanged - native implementation does exactly what users > > already implemented > > 2. Migration is trivial - simply remove the redundant method > > 3. Precedent exists - PHP 8.1 native enums broke myclabs/php-enum > > (4.9k stars) similarly > > 4. Long-term benefit - standardization, discoverability, elimination > > of boilerplate > > 5. No alternative - virtual properties are technically infeasible; > > different name doesn't match community expectations > > Here I don't agree! > > PHP application especially libraries and frameworks very often have to > support multiple PHP versions. They can't just remove an already > implemented function and drop support for all previous PHP versions at once. > > So either, the new function will not be final - to allow getting > overwritten by current implementations - in this case you would need to > run another analytics to check for naming clashes with different > incompatible signature or behavior. > > Or it needs to kind of deprecation period or another name. > > > Just my 2 cents > > Marc
I think it would be ok to break it but only in a major version like PHP 9. No deprecation needed.
