Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129205
Precedence: list
MIME-Version: 1.0
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>
In-Reply-To: <34c08e21-8cd1-2e0e-1cca-148d4acc5432@php.net>
Date: Wed, 12 Nov 2025 14:35:52 +0300
Message-ID: <CAJYrtd9OgtkOV8U=eqxegukj=_rL9GVyFPkebfKoWAgJGkRcRw@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Add values() Method to BackedEnum
To: Derick Rethans <derick@php.net>
Cc: Valentin Udaltsov <udaltsov.valentin@gmail.com>, php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000064d3a80643642b5f"
From: mikhail.d.savin@gmail.com (Mikhail Savin)

--00000000000064d3a80643642b5f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=D0=B2=D1=82, 11 =D0=BD=D0=BE=D1=8F=D0=B1. 2025=E2=80=AF=D0=B3. =D0=B2 14:5=
0, Derick Rethans <derick@php.net>:

> On Tue, 11 Nov 2025, Mikhail Savin wrote:
>
> > The RFC addresses this by adding "public static function values(): arra=
y"
> > 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=E2=80=99s a .phpt demonstrating the intended behavior:
> >
> > --TEST--
> > Backed enums: user-defined values() incompatible with interface signatu=
re
> > --FILE--
> > <?php
> >
> > enum E: string {
> >     case A =3D 'a';
> >
> >     // Intentional incompatibility: interface requires array return typ=
e
> >     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

--00000000000064d3a80643642b5f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g=
mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">=D0=B2=D1=82, 1=
1 =D0=BD=D0=BE=D1=8F=D0=B1. 2025=E2=80=AF=D0=B3. =D0=B2 14:50, Derick Retha=
ns &lt;<a href=3D"mailto:derick@php.net">derick@php.net</a>&gt;:<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">On Tue, 11 Nov 2025, Mikha=
il Savin wrote:<br>
<br>
&gt; The RFC addresses this by adding &quot;public static function values()=
: array&quot;<br>
&gt; to the BackedEnum interface itself.<br>
&gt; With that in place, an enum that defines an incompatible values() will=
 fail<br>
&gt; at compile time with a normal method-signature incompatibility, exactl=
y<br>
&gt; like it would for from()/tryFrom().<br>
&gt; <br>
&gt; Here=E2=80=99s a .phpt demonstrating the intended behavior:<br>
&gt; <br>
&gt; --TEST--<br>
&gt; Backed enums: user-defined values() incompatible with interface signat=
ure<br>
&gt; --FILE--<br>
&gt; &lt;?php<br>
&gt; <br>
&gt; enum E: string {<br>
&gt;=C2=A0 =C2=A0 =C2=A0case A =3D &#39;a&#39;;<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0// Intentional incompatibility: interface requires =
array return type<br>
&gt;=C2=A0 =C2=A0 =C2=A0public static function values(): string {<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return &#39;values&#39;;<br>
&gt;=C2=A0 =C2=A0 =C2=A0}<br>
&gt; }<br>
&gt; <br>
&gt; ?&gt;<br>
&gt; --EXPECTF--<br>
&gt; Fatal error: Declaration of E::values(): string must be compatible wit=
h<br>
&gt; BackedEnum::values(): array in %s on line %d<br>
<br>
Right now, enums can have a &quot;values()&quot; function that can return a=
nything <br>
I desire: an array of enum cases, or objects created from these, or <br>
strings, or M_PI.<br>
<br>
If it has to be compatible with<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 `BackedEnum::values(): array(int|string)`<br>
<br>
(which is what your contract demands, even though it can&#39;t express the =
<br>
int|string part)<br>
<br>
Then that is a BC break again.<br>
<br>
cheers,<br>
Derick</blockquote><div><br>Hi, guys, thanks for feedback<br><br></div>Foll=
owing the discussion with Alex and Derick, I&#39;ve completed a comprehensi=
ve BC <br>analysis. I need community input on a key decision: whether to in=
clude a return <br>type in the interface declaration.<br><br>## The Two Opt=
ions<br><br>**Option A: WITH return type (current PR)**<br>```php<br>interf=
ace BackedEnum {<br>=C2=A0 =C2=A0 public static function values(): array;<b=
r>}<br>```<br>- BC Breaks: 71-600 implementations (1.0-8.8%)<br>- Better ty=
pe safety and IDE support<br>- Consistent with cases(): array<br><br>**Opti=
on B: WITHOUT return type (alternative)**<br>```php<br>interface BackedEnum=
 {<br>=C2=A0 =C2=A0 public static function values();<br>}<br>```<br>- BC Br=
eaks: 0 (0%)<br>- All existing implementations compatible<br>- Can add `: a=
rray` in PHP 9.0<br><br>## BC Analysis Data<br><br>Total enums with values(=
): 6,800<br>- Compatible (: array): 6,200 (91.2%)<br>- Missing return type:=
 64 (0.9%)<br>- Wrong return types: 7 (0.1%)<br>- Unaccounted: ~529 (7.8%)<=
br><br>All GitHub search links: <a href=3D"https://github.com/php/php-src/p=
ull/20398">https://github.com/php/php-src/pull/20398</a><br><br>## Question=
 for Community<br><br>Which approach should we take for PHP 8.6?<br><br>**O=
ption A:** Accept 1-9% BC break for full type safety<br>**Option B:** Zero =
BC breaks, add typing in PHP 9.0<br><br>I&#39;m inclined toward Option B (z=
ero breaks for 8.6), but want to hear community <br>preference before chang=
ing the implementation.<br><br>Thoughts?<br><br>---<br>Additional context:<=
br>- Implementation change is trivial (one line)<br>- Native implementation=
 returns array regardless of interface<br>- Alex&#39;s array_column suggest=
ion incorporated (+3.6k usages)<br><div>- All data verifiable via GitHub se=
arches in PR=C2=A0<br><br><br></div>Best regards, Mikhail<br><br><br></div>=
</div>

--00000000000064d3a80643642b5f--