Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127977
Precedence: bulk
MIME-Version: 1.0
References: <CADK1yXLAOgDNrXO1-t0vLKCtV2qB4L2x50JFHXxJHoUrA6GPsA@mail.gmail.com>
 <5a38b818-8366-4edc-93ab-a147e3a9aec3@app.fastmail.com>
In-Reply-To: <5a38b818-8366-4edc-93ab-a147e3a9aec3@app.fastmail.com>
Date: Wed, 9 Jul 2025 13:39:23 -0300
Message-ID: <CADK1yX+6jy6tCtBM7vwwee+jeRy460Ww4ib1JSi0V=aBGMA+Uw@mail.gmail.com>
Subject: Re: [PHP-DEV] ::from() and tryFrom() on Basic Enums
To: Rob Landers <rob@bottled.codes>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="0000000000004e26a6063981baf9"
From: deleugyn@gmail.com (Deleu)

--0000000000004e26a6063981baf9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Jul 9, 2025 at 1:17=E2=80=AFPM Rob Landers <rob@bottled.codes> wrot=
e:

>
> Hey Marco,
>
> I think this relies on whether the =E2=80=9Cnatural value=E2=80=9D of a u=
nit enum is a
> string or not. It might be, or it might not be. I don=E2=80=99t 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=E2=80=99ve been thinking=
 of a
> =E2=80=9Cquality-of-life RFC=E2=80=9D for obvious enums, for some time no=
w. Basically,
> backed enums without a value receive the =E2=80=9Cobvious=E2=80=9D 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 =E2=80=9Cnatural value=E2=80=9D of a unit enum is.
>
> =E2=80=94 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.

--=20
Marco Deleu

--0000000000004e26a6063981baf9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g=
mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Jul 9, =
2025 at 1:17=E2=80=AFPM Rob Landers &lt;rob@bottled.codes&gt; wrote:<br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u><div><div><br><=
/div><div>Hey Marco,</div><div><br></div><div>I think this relies on whethe=
r the =E2=80=9Cnatural value=E2=80=9D of a unit enum is a string or not. It=
 might be, or it might not be. I don=E2=80=99t think you have a compelling =
argument on why it is a string and that string is the name. Personally, I u=
sed int-backed enumerations far more so I would argue that the natural valu=
e is an integer, not a string. I=E2=80=99ve been thinking of a =E2=80=9Cqua=
lity-of-life RFC=E2=80=9D for obvious enums, for some time now. Basically, =
backed enums without a value receive the =E2=80=9Cobvious=E2=80=9D value. S=
o a string backed enum gets the name, while an int gets the ordered number.=
=C2=A0</div><div><br></div><div>I think something like that makes more sens=
e than trying to decide what the =E2=80=9Cnatural value=E2=80=9D of a unit =
enum is.=C2=A0</div><div><br></div><div id=3D"m_-3280713595941587705sig1212=
29152">=E2=80=94 Rob</div></div></blockquote></div><div><br clear=3D"all"><=
/div><div>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 stre=
ngthens my desire for Larry&#39;s suggestion for String-backed Enums defaul=
ting 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 th=
at could conflict with userland and it also makes it opt-in. By adding `: s=
tring` to a Unit Enum, we make the `-&gt;value` equivalent to the `-&gt;nam=
e` and receive the from() implementation for it.</div><div><br></div><div>I=
t&#39;s currently undeniable that a Unit Enum name is a string.</div><div><=
br></div><span class=3D"gmail_signature_prefix">-- </span><br><div dir=3D"l=
tr" class=3D"gmail_signature"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D=
"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr">M=
arco Deleu</div></div></div></div></div></div></div></div></div>

--0000000000004e26a6063981baf9--