Re: [RFC][Under discussion] Fetch properties in const expressions

On Mon, Jun 27, 2022 at 10:16 AM Rowan Tommins <rowan.collins@gmail.com> wrote: > > On 27/06/2022 08:38, Marc Bennewitz wrote: > > Now as I have a lot of such classes and I want to make sure all of the > > prefixes are unique so I added an enum with all prefixes and use the > > enum value as constant value as well. > > > > enum IdPrefix:string > > { > > case USER_ID = 'u-'; > > // ... > > } > > > This would never have occurred to me as a design, because I had no idea > that the values of backed enums were enforced to be unique. I'm not sure > if it can be considered "taking advantage of a side-effect", or if > people always expected backed enums to be used that way. > > Ultimately, that's my reaction to both the enum-related RFC currently > under discussion: I don't really understand what backed enums are > intended for in the first place, so find it hard to judge whether > expanding them in a particular way makes sense. If a string-backed enum > can be considered just a unique set of strings, then it really has very > little in common with how I think of (unbacked) enums, but maybe that's > fine. > > Regards, > > -- > Rowan Tommins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > I think it is fair to consider backed enums a "set" vs. "enum." A good use-case for integer-backed enums would be HTTP response codes, however, the standard library only accepts integers (http_response_code(), for example) and it would be nice if it either accepted built-in enums or automatically cast integer-backed enums to int. However, the latter probably makes more sense simply because response codes are changing slightly, and will continue to evolve: https://www.rfc-editor.org/rfc/rfc9110#section-15 (some 4xx codes have been removed IIRC). Robert Landers Software Engineer Utrecht NL