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

From: Date: Tue, 11 Nov 2025 11:50:21 +0000
Subject: Re: [RFC] [Discussion] Add values() Method to BackedEnum
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to internals+get-129198@lists.php.net to get a copy of this message
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

« previous php.internals (#129198) next »