Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128635
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Thu, 04 Sep 2025 08:56:51 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <b7e870eb-9012-4fff-bd28-6a4a817a9181@app.fastmail.com>
In-Reply-To: <25e79d21-7b7f-4d7f-b5cb-1e9cfd0aa657@varteg.nz>
References: <9c875e83-ddc8-4c5c-a368-747bef46e4a2@app.fastmail.com>
 <F60093E2-9310-4E6D-B1CA-C4B98D60B097@mabe.berlin>
 <25e79d21-7b7f-4d7f-b5cb-1e9cfd0aa657@varteg.nz>
Subject: Re: [PHP-DEV] enum flag backed enum
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Wed, Sep 3, 2025, at 7:20 PM, Morgan wrote:
> On 2025-09-04 09:23, Marc B. wrote:
>>>
>>> Attempting to use a backed value that is not a power-of-two would re=
sult in a compilation error. Bitwise operations are performed as though =
they=E2=80=99re performed on a regular integer.
>>>
>>> What do you think?
>>=20
>> I think what we actually would need is an EnumSet which can be used w=
ith any enum but (based on its ordinal) but this would play nicely toget=
her with generics `new EnumSet<JsonOption>`.
>>=20
>
> Agreed; using enums-backed-by-powers-of-two is just a way to encode se=
ts=20
> of values drawn from an enum (it's a way to enumerate the possible=20
> subsets of a set). It should be possible to have a set of Enum values=20
> for any Enum, rather than break the Enum type concept by exposing=20
> implementation details, and allow sets for some types but not others=20
> depending on how they are serialised.
>
> A class can be built in userspace as a "SetOfEnum"; or such a class=20
> could be added to the standard library; or even have, for each Enum=20
> declared, an EnumSet (final) class is also implicitly declared.

It feels like there's two different related topics here.

One is using enums as a way to define a set of bit flags rather than con=
stants.  I'm not sure if this is necessary, but if so, I'd expect a bit =
more automation than the initial proposal here.  The statement that bitw=
ise operations would fall back to integer ops makes me think it falls in=
to the "fancy constants" category we have tried to avoid.

The other is enum sets, which I am very much in favor of but designing t=
hose in a clean way is non-trivial.  My collections research with Derick=
 a while back included a `Set` type, which also supported operator overr=
ides for the |, <, <=3D, -, and other operators, so it did effectively g=
ive a very nice enum set syntax.  Whether that is the optimal approach o=
r not is unclear.  But an Enum Set feature should work with any enum.  (=
And of course runs into the eternal generics question.)

So, Rob, which one are you really talking about?

--Larry Garfield