Re: [RFC] [Discussion] BackedEnum::values() - Seeking feedback before formal RFC
On Thu, 6 Nov 2025 at 05:35, Marc B. <marc@mabe.berlin> 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.
Thread (9 messages)