вт, 11 нояб. 2025 г. в 14:50, Derick Rethans <[email protected]>:
> 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
