Re: [Discussion] Implicitly backed enums

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: https://github.com/Crell/enum-comparison And I wrote an article about enum usage a while back here: https://peakd.com/hive-168588/@crell/on-the-use-of-enums --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.