On Wed, Jul 9, 2025 at 1:17 PM Rob Landers <rob@bottled.codes> wrote:
> > Hey Marco, > > I think this relies on whether the “natural value” of a unit enum is a > string or not. It might be, or it might not be. I don’t think you have a > compelling argument on why it is a string and that string is the name. > Personally, I used int-backed enumerations far more so I would argue that > the natural value is an integer, not a string. I’ve been thinking of a > “quality-of-life RFC” for obvious enums, for some time now. Basically, > backed enums without a value receive the “obvious” value. So a string > backed enum gets the name, while an int gets the ordered number. > > I think something like that makes more sense than trying to decide what > the “natural value” of a unit enum is. > > — Rob > It makes sense that if a Unit Enum were to be given a `value` we would have a hard time defining what type such value should have. This strengthens my desire for Larry's suggestion for String-backed Enums defaulting to their names. That way, we sidestep the issue of the value type of a Unit Enum, we avoid a potential breaking change by introducing a method that could conflict with userland and it also makes it opt-in. By adding `: string` to a Unit Enum, we make the `->value` equivalent to the `->name` and receive the from() implementation for it. It's currently undeniable that a Unit Enum name is a string. -- Marco Deleu
