Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129212
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Wed, 12 Nov 2025 13:01:06 -0600
To: "php internals" <internals@lists.php.net>
Message-ID: <a6b66245-5acc-49dc-9f6c-2de46d545ee2@app.fastmail.com>
In-Reply-To: 
 <CAJYrtd9OgtkOV8U=eqxegukj=_rL9GVyFPkebfKoWAgJGkRcRw@mail.gmail.com>
References: 
 <CAJYrtd_YrEnpSPjkQoQqFGVKOOf_sDgNf+=rtP=pxF1Bik4o2w@mail.gmail.com>
 <CAPyeZ4Nq=S=QOLVqVhNGNN+BD3yByaLfB7NeHnaYCv2UaYGDLQ@mail.gmail.com>
 <CAJYrtd8y9b6jOWNA5gB_vT5mnTijJ302JoSQd2ZTvyrdOotduQ@mail.gmail.com>
 <34c08e21-8cd1-2e0e-1cca-148d4acc5432@php.net>
 <CAJYrtd9OgtkOV8U=eqxegukj=_rL9GVyFPkebfKoWAgJGkRcRw@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Add values() Method to BackedEnum
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
From: larry@garfieldtech.com ("Larry Garfield")

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