Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129109
Message-ID: <b889b31b-502c-4e8d-9039-7ba63e1ca386@mabe.berlin>
Date: Thu, 6 Nov 2025 06:35:34 +0100
Precedence: list
MIME-Version: 1.0
Subject: Re: [PHP-DEV] [RFC] [Discussion] BackedEnum::values() - Seeking
 feedback before formal RFC
To: internals@lists.php.net
References: <CAJYrtd-6ikRT2X5NZHCbC6UsX1VRn2R5pTT4hb-r-YujYjTHqQ@mail.gmail.com>
Content-Language: en-US
In-Reply-To: <CAJYrtd-6ikRT2X5NZHCbC6UsX1VRn2R5pTT4hb-r-YujYjTHqQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: marc@mabe.berlin ("Marc B.")

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