Re: [RFC] [Discussion] Add values() Method to BackedEnum

From: Date: Wed, 12 Nov 2025 11:35:52 +0000
Subject: Re: [RFC] [Discussion] Add values() Method to BackedEnum
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-129205@lists.php.net to get a copy of this message
вт, 11 нояб. 2025 г. в 14:50, Derick Rethans <derick@php.net>: > On Tue, 11 Nov 2025, Mikhail Savin wrote: > > > The RFC addresses this by adding "public static function values(): array" > > to the BackedEnum interface itself. > > With that in place, an enum that defines an incompatible values() will > fail > > at compile time with a normal method-signature incompatibility, exactly > > like it would for from()/tryFrom(). > > > > Here’s a .phpt demonstrating the intended behavior: > > > > --TEST-- > > Backed enums: user-defined values() incompatible with interface signature > > --FILE-- > > <?php > > > > enum E: string { > > case A = 'a'; > > > > // Intentional incompatibility: interface requires array return type > > public static function values(): string { > > return 'values'; > > } > > } > > > > ?> > > --EXPECTF-- > > Fatal error: Declaration of E::values(): string must be compatible with > > BackedEnum::values(): array in %s on line %d > > Right now, enums can have a "values()" function that can return anything > I desire: an array of enum cases, or objects created from these, or > strings, or M_PI. > > If it has to be compatible with > > BackedEnum::values(): array(int|string) > > (which is what your contract demands, even though it can't express the > int|string part) > > Then that is a BC break again. > > cheers, > Derick Hi, guys, thanks for feedback Following the discussion with Alex and Derick, I've completed a comprehensive BC analysis. I need community input on a key decision: whether to include a return type in the interface declaration. ## The Two Options **Option A: WITH return type (current PR)** ```php interface BackedEnum { public static function values(): array; } ``` - BC Breaks: 71-600 implementations (1.0-8.8%) - Better type safety and IDE support - Consistent with cases(): array **Option B: WITHOUT return type (alternative)** ```php interface BackedEnum { public static function values(); } ``` - BC Breaks: 0 (0%) - All existing implementations compatible - Can add : array in PHP 9.0 ## BC Analysis Data Total enums with values(): 6,800 - Compatible (: array): 6,200 (91.2%) - Missing return type: 64 (0.9%) - Wrong return types: 7 (0.1%) - Unaccounted: ~529 (7.8%) All GitHub search links: https://github.com/php/php-src/pull/20398 ## Question for Community Which approach should we take for PHP 8.6? **Option A:** Accept 1-9% BC break for full type safety **Option B:** Zero BC breaks, add typing in PHP 9.0 I'm inclined toward Option B (zero breaks for 8.6), but want to hear community preference before changing the implementation. Thoughts? --- Additional context: - Implementation change is trivial (one line) - Native implementation returns array regardless of interface - Alex's array_column suggestion incorporated (+3.6k usages) - All data verifiable via GitHub searches in PR Best regards, Mikhail

« previous php.internals (#129205) next »