On Mon, Mar 16, 2026, at 10:48 AM, Tim Düsterhus wrote: > Hi > > Am 2026-03-13 19:11, schrieb Larry Garfield: >> Otherwise, there's no real advantage to putting it in core rather than >> FIG. The reason to put it in core is so it can be used in core. So >> let's use it in core, even if not the full scope of eventual usage. > > I believe the RFC is sufficiently clear in how the enum can be useful > for the PHP stdlib, listing some examples as future scope. And even if > there would not (yet) be anything in the stdlib that could make use of > it, I believe that asking users to install third party libraries with > vendor-namespaces for a *data type* that is so broadly useful that it > will likely be (transitively) required by every major framework is > providing a good developer experience. > > Best regards > Tim Düsterhus
To be clear, I'm not suggesting that FIG would be a better place for it. I am only saying that "let's add this... and then maybe later we'll get around to quietly using it without another RFC" is a poor message and poor expectation setting. When will I be able to use it for core functions? Which functions? How will I even know? What's the plan here other than "we can do that later quietly without telling anyone" (because vanishingly few PHP devs look at Internals PRs that have no RFC)? That's what is missing. --Larry Garfield
