Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125047
Precedence: bulk
MIME-Version: 1.0
References: <2A3FFD56-789F-4ECF-8E9F-A84804E484D1@getmailspring.com>
In-Reply-To: <2A3FFD56-789F-4ECF-8E9F-A84804E484D1@getmailspring.com>
Date: Mon, 19 Aug 2024 09:10:06 -0600
Message-ID: <CAAKU0ukpsOtQKFtq3rfTHr-33aDWRCxoV0UAHDDx3QZv6672mQ@mail.gmail.com>
Subject: Re: [PHP-DEV] String enums & __toString()
To: John Coggeshall <john@coggeshall.org>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: levi.morrison@datadoghq.com (Levi Morrison)

On Fri, Aug 16, 2024 at 1:43=E2=80=AFPM John Coggeshall <john@coggeshall.or=
g> wrote:
>
> Hey all,
>
> I poked around a bit in the Enum RFCs and I could find (maybe I missed) w=
hat's up with this:
>
> enum Foo:string implements \Stringable
> {
>     case FOO =3D 'bar';
>
>     public function __toString() {
>         return $this->value;
>     }
> }
>
> PHP Fatal error:  Enum Foo cannot include magic method __toString
>
> It seems to me that when the enum is a string  it is entirely reasonable =
to expect __toString()  to work here and support the \Stringable  interface=
.
>
> Is there a reason I'm missing as to why this is problematic in the engine=
 that's been documented somewhere, or is this an oversight we can look at c=
orrecting?
>
> John

As others have said, there are definite objections to
auto-implementing string conversions. I think that opt-in string
conversions are sufficiently different that you would have a shot at
an RFC passing. No guarantees about that, of course!