Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123392
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-480-g515a2f54a-fm-20240515.001-g515a2f54
Precedence: bulk
MIME-Version: 1.0
Message-ID: <1286eed1-c35e-40ec-a6f0-84926c99c911@app.fastmail.com>
In-Reply-To: <99c30f5d-e2f3-4027-a8fc-b3b9c71fb6d1@scriptfusion.com>
References: <fcb90d5b-ac31-49b5-bf72-ed8654c34053@scriptfusion.com>
 <da922505-5cb3-44ac-916c-fbb7f864707b@app.fastmail.com>
 <99c30f5d-e2f3-4027-a8fc-b3b9c71fb6d1@scriptfusion.com>
Date: Tue, 21 May 2024 18:31:14 -0500
To: "php internals" <internals@lists.php.net>
Subject: Re: [PHP-DEV] [Discussion] Implicitly backed enums
Content-Type: text/plain
From: larry@garfieldtech.com ("Larry Garfield")

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:
>>
>> 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.

"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