Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129115
Precedence: list
MIME-Version: 1.0
References: <CAJYrtd-6ikRT2X5NZHCbC6UsX1VRn2R5pTT4hb-r-YujYjTHqQ@mail.gmail.com>
 <b889b31b-502c-4e8d-9039-7ba63e1ca386@mabe.berlin>
In-Reply-To: <b889b31b-502c-4e8d-9039-7ba63e1ca386@mabe.berlin>
Date: Thu, 6 Nov 2025 14:06:46 +0000
Message-ID: <CAGBsUrcaGLWp18b1zBd854pHeqZaTn84GMgm7TL0yQv-dnsZbw@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] BackedEnum::values() - Seeking
 feedback before formal RFC
To: "Marc B." <marc@mabe.berlin>
Cc: internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
From: tekiela246@gmail.com (Kamil Tekiela)

On Thu, 6 Nov 2025 at 05:35, Marc B. <marc@mabe.berlin> wrote:
>
> Hi Savin,
>
> Thanks for sharing your idea.
>
> On 06.11.25 05:09, Mikhail Savin wrote:
> > Hi internals,
> >
> > I would like to propose adding a native values() method to the BackedEnum
> > interface that returns an array of all backing values. Before creating a
> > formal RFC, I'm seeking feedback on the concept and approach.
> >
> > == Summary ==
> >
> > The proposal adds:
> >
> >     interface BackedEnum {
> >         public static function values(): array;
> >     }
> >
> > This would allow:
> >
> >     enum Status: string {
> >         case Active = 'active';
> >         case Inactive = 'inactive';
> >     }
> >
> >     Status::values(); // ['active', 'inactive']
> >
> > == Motivation ==
> >
> > This pattern is extremely common in the wild. Based on GitHub code search:
> >
> >   * ~3,860+ direct implementations of this exact pattern
> >   * ~20,000-40,000 estimated real usage when accounting for shared traits
> >   * Used in major frameworks: Symfony core (TypeIdentifier.php),
> >     Laravel ecosystem
> >   * Documented by PHP.net: The manual itself shows EnumValuesTrait as
> >     an example
> >
> > Common use cases:
> >   * Database migrations: $table->enum('status', Status::values())
> >   * Form validation: $validator->rule('status', 'in', Status::values())
> >   * API responses: ['allowed_statuses' => Status::values()]
>
> I agree, this is a common feature I would like as well.
>
> >
> > == Backward Compatibility - Important Discussion Point ==
> >
> > This is a breaking change. Enums that already define a values() method
> > will fail with:
> >
> >     Fatal error: Cannot redeclare BackedEnum::values()
> >
> > Based on ecosystem research:
> >   * ~24,000-44,000 enum instances will break
> >   * All implementations are functionally identical to what's being
> > proposed
> >   * Migration is mechanical: just delete the user-defined method
> >
> > The break is justified because:
> >
> >   1. Behavior is unchanged - native implementation does exactly what users
> >      already implemented
> >   2. Migration is trivial - simply remove the redundant method
> >   3. Precedent exists - PHP 8.1 native enums broke myclabs/php-enum
> >      (4.9k stars) similarly
> >   4. Long-term benefit - standardization, discoverability, elimination
> >      of boilerplate
> >   5. No alternative - virtual properties are technically infeasible;
> >      different name doesn't match community expectations
>
> Here I don't agree!
>
> PHP application especially libraries and frameworks very often have to
> support multiple PHP versions. They can't just remove an already
> implemented function and drop support for all previous PHP versions at once.
>
> So either, the new function will not be final - to allow getting
> overwritten by current implementations - in this case you would need to
> run another analytics to check for naming clashes with different
> incompatible signature or behavior.
>
> Or it needs to kind of deprecation period or another name.
>
>
> Just my 2 cents
>
> Marc

I think it would be ok to break it but only in a major version like
PHP 9. No deprecation needed.