On Wed, Nov 12, 2025, at 5:35 AM, Mikhail Savin wrote:
> 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
Isn't this what the #[ReturnTypeWillChange] attribute was intended for?
cf: https://wiki.php.net/rfc/internal_method_return_types
That seems like an option C? It's technically a BC break, but people can just
drop an attribute on it to disable the return type check until 9.0. We did the
same for the various internal methods, as noted in that RFC.
--Larry Garfield
