to me, this looks like a use case for using constants rather than a BackedEnum. Using PHP enums makes sense when you typehint them, providing type safety. Here, you allow any enum case just to read its backing value, which voids all benefits of the enum.

@stof Thanks for your reply. In this case, using the enum only for this might not make sense. But in our system, we use the enum to typehint other attributes etc. For example:

#[ObjectType(
    schema: GraphQLSchema::PUBLIC,
    name: 'Movie',
)]
final class MovieType

The attribute's signature would look like this:

public function __construct(
        public readonly GraphlQLSchema $schema,
        public readonly string $name,
    ) {
    }

Now we get full type safety wherever we use the GraphQLSchema.

Since PHP 8.1 doesn't allow you to do this:

public function __construct(
  #[Target(GraphQLSchema::PUBLIC->value)]
  private Schema $schema
) {}

or this:

public function __construct(
  #[Target((string) GraphQLSchema::PUBLIC)]
  private Schema $schema
) {}

the only way to use the enum is to either get support in Target attribute, or to just have a separate constant instead.

I wish PHP would just automatically cast an BackedEnum (string) to a string when the function requires a string.

the only way to use the enum is to either get support in Target attribute, or to just have a separate constant instead.

Hmm, php since version 8.1 allows nested attributes, so you can do something with casting to a string:

#[SomeAttribute(new AsString(Test::A))]
class SomeClass {}

@korkoshko But that still won't work for the Target attribute as that only accepts string.

@ruudk if you don't use a strict types declaration, php will auto cast the object to a string if it implements Stringable.

To fully support strict types, it might be better to add a union type string|Stringable to Target.

This is really touching a deficiency of the language and enums in this case IMHO. They are really invading the codebase in a way that makes everything more complex. Like you said: "more attributes would support using enums but that's another discussion".

Fixing one "random" attribute doesn't make sense to me. I'd rather look for a more generic approach to them. eg string|Stringable is a bit more generic, but that'd require enums to have a __toString. I might be fine with forcing them all to have that method if they want such support. Also, the engine should provide a default __toString implementation for BackedEnum to me.

this looks like a use case for using constants rather than a BackedEnum

This might also be The generic solution I'm looking for. Enums being the new toy in school, we might be trying to use them when they don't fit - or where consts would fit better.

BTW: shouldn't BackedEnum::from(int|string) be turned into ::from(int|string|Stringable|static)?

/cc @Crell

but that'd require enums to have a __toString

… which is not allowed btw:

https://3v4l.org/m1cKu

Fatal error: Enum may not include __toString in /in/m1cKu on line 3

If we take this upstream to PHP core, I think we should try to make something like this possible:

#[MyAttribute(MyEnum::FOO->value)]

Right now, it is not: https://3v4l.org/NI78X

#[MyAttribute(MyEnum::FOO->value)]

This would be perfect.

Implementing Stringable + __toString on a string backed enum would be great too.

__toString was deliberately left off of enums because we weren't sure what the right behavior would be and wanted to see it in the wild for a while first. So running into issues like this is good, because it helps to see what the use cases are. Also, we aren't sure yet if it would cause issues with ADTs if/when those get implemented.

#[MyAttribute(MyEnum::FOO->value)]

This is currently blocked by -> not being allowed as part of a "constant expression." There's an open core issue about it:

php/php-src#8344

It sounds like no no one is against fixing that; someone just needs to do the work and file an RFC. That would be the best solution here, IMO.

So running into issues like this is good

Yes and no :)
Yes from the pov of the engine, as it forces feedback from userland and can help make the best decision.
No from the pov of eg Symfony, because the community wants to use enums no matter their limitations and we are all kinda confused about what is a work around a "by design" limitation vs what is legit design.

Take eg this PR. I'm not keen to accept it, and I'm not keen either with letting the community in a state where they cannot use enums before some hypothetical improvement in the future.

I'm not sure this process followed by enums is beneficial for the community, for this reason...
Eg what should we do here now?

@nicolas-grekas I think, we encountered a similar situation with attributes where the implementation that shipped with PHP 8.0 did not include nesting. We've discussed various workarounds back then and decided to wait for PHP to implement that missing feature properly.

If #[MyAttribute(MyEnum::FOO->value)] is shipped with PHP 8.2, I'd vote for rejecting this PR.

Best course of action here, I think, is to help get the core issue resolved for 8.2 and reject this PR, as fixing the core issue will make this irrelevant.

Closing the while we wait for 8.2 to improve.

RFC: https://wiki.php.net/rfc/fetch_property_in_const_expressions

This might be the improvement we're looking for: php/php-src#8825