On Tue, Mar 3, 2026, at 2:50 PM, Tim Düsterhus wrote: > Hi > > On 3/3/26 01:36, Larry Garfield wrote: >> I concur. I'd like to see the functions updated now in the RFC, so we get a >> sense of how many functions will be impacted. Not because I'm concerned >> about a widened type breaking anything, but more so readers can see the >> value this brings. > > I see the main value in helping userland not to reinvent the wheel every > time and to set some further precedent in including types for this kind > of ubiquitous concept in the standard library. > > I don't want to commit to supporting the enum for every possible > function in the standard library for the reasons I mentioned in my reply > to Bob and also because some of the functions already have a very messy > API signature where backfitting the enum is not exactly trivial.
I'm not suggesting we update every single function in one RFC shot. But the RFC should include updating at least one or two so that the Enum is actually used. 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. --Larry Garfield
