On Tue, May 21, 2024, at 5:48 PM, Bilge wrote:
On 21/05/2024 23:35, Larry Garfield wrote:
On Tue, May 21, 2024, at 5:30 PM, Bilge wrote:
Hi Internals,
I struggle to understand the benefit of "basic" enumerations and their
diminished API. In particular, I often find myself wanting to use
`from()/``tryFrom()` to convert a string to an enumeration. To do this,
I must convert it to a "backed" enum and copy & paste each name to its
value. In all other regards, I still want it to behave like a "basic"
enumeration, so I won't abuse the value of the names to act like a
mapping; the values will always mirror the names, and if I need to do
any mappings, I'll add match() functions.
My question, then, is why can't basic enumerations have these semantics
by default? Or, to state it more concretely, what would be the downside
to having all "basic" enumerations actually being "backed" enumerations
whose values implicitly mirror their names for the purposes of
converting to/from strings? Would this not make basic enumeration more
useful without any particular downsides?
Kind regards,
Bilge
Making enums not be "fancy strings" was a very deliberate decision. The RFC covers that some. There's more information in our comparison research here:
GitHub - Crell/enum-comparison: A comparison of enumerations and similar features in different languages
And I wrote an article about enum usage a while back here:
On the use of enums | PeakD
--Larry Garfield
Hi Larry,
Thanks for the resources! Whilst I can appreciate this was a deliberate
design decision that did not come about by accident, I still didn't find
(skimming) anything that directly answers the question:
>What would be the downside to having all "basic" enumerations actually
being implicitly "backed" enumerations?
I gather from your (presumably derogatory) referencing of the same as
"fancy strings" that you would not approve such an implementation, but I
am struggling to understand why.
Cheers,
Bilge
P.S. Sorry for the (previously) incomplete subject line.
"Fancy strings" isn't derogatory. It's an accurate description of how enums work in some languages. (Although usually they're "fancy ints", rather than strings.) The model PHP went with is "fancy objects" (also used by most other languages at this point).
From the article I linked:
Enumerations take that a step further by allowing you to define an entirely new type space of values. Just as a Request object is not an integer, neither is a Direction enumeration with values Up and Down an integer. If a function takes an integer as a parameter, and you try to pass it a Request, both the code and the developer are going to just look at you funny. The exact same concept applies if you try to pass a Direction enum to an integer parameter.
And also see the "These things are not the same" section.
In your case, you want to "upcast" a string to an enum. That means you're doing some sort of deserialization, presumably. In that case, a backed enum is what you want. A unit enum isn't serializable, by design.
Now, it's true we didn't try to come up with all the possible shorthands that might make sense. I could see an argument for auto-populating the backing value off the enum name if it's not specified, something like this:
enum Options: string {
case First; // This implicitly gets "First"
case Second = '2nd';
}
We left that out of the original RFC to keep things simple and avoid (well, reduce) bikeshedding side quests. However, I think it's a fair discussion to have on whether it makes sense to do that, or similar. I'm not sure if I'd support it myself at the moment (there would also be questions about what happens with an int-backed enum), but I think it's a reasonable discussion to have.
--Larry Garfield
