Hi Nicolas, thanks for the RFC, > There are also cases where using "->value" is just not possible. I mention > attributes in the RFC,
which also mentions https://wiki.php.net/rfc/fetch_property_in_const_expressions (but with "For people that use non-strict mode, this extra “->value” is boilerplate that they'd better remove") > but we also have a case in Symfony where defining > service definitions in yaml doesn't work with enums because there is no way > to express the "->value" part. Symfony YAML has a `!php/const X` feature, which also works when X is an Enum::CASE; how about a `!php/enum_value` feature? Otherwise, I also like Rowan's suggestion of implementing "internal cast handlers", so that non-strict users could call e.g. `takes_int(IntEnum::CASE)` as well as `takes_string(StringEnum::CASE)`; but what about `takes_string(IntEnum::CASE)`, and `takes_Stringable(StringEnum::CASE)`? In any case, several people requested that it should require to be *opted-in* explicitly; but then [for solutions other than "allowing user-land to implement Stringable"] we probably also need a way to test whether a BackedEnum [instance] is "coercible"? Regards, -- Guilliam Xavier -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
