-
Notifications
You must be signed in to change notification settings - Fork 659
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add backed enum type annotation #10907
base: 5.x
Are you sure you want to change the base?
Add backed enum type annotation #10907
Conversation
…efault as the backed type is already inferred by the code structure
… of the backed type
I wonder why this phpdoc typing is necessary. All enum values are known at static analysis time, so why doesn't psalm just turn the |
and how will you know the type of the enum you want to infer? let's say you want an enum having only non-empty-string. how would you know this? |
so you want a type which accepts any enum which is backed by a string? I can't think of a use-case for such a vague type. couldn't you accept any |
well, when you do enum MyEnum: string{...} aren't your already doing it? i just want to be strict about the types to pass in an enum, i would like to have enum having non empty strings as i would have classes with properties that are non empty string |
you can't pass a type into a enum. every enum has a native type per default and cannot be defined in a wrong way without a fatal runtime error, e.g. https://3v4l.org/VlZAK I don't see which information psalm could take from the phpdoc which is not already there by the raw definition. don't get me wrong: I am not a psalm developer, so I just share my thoughts. |
Checking that the backed type is the same as the case value is not the main goal of this pr even if it's a subcase of it. Actually the main goal of the pr is to say that you want to infer a subtype of the backed type in order to have an enum whose case values respect both types.
you would get an error. |
My main issue here is that it will make any BackedEnum mandatory to be templated. If PHPStan doesn't, it will lead to complains about not being able to use both. It could be great to discuss it with them to know if it can be implemented on their side (and if they agree with the feature) |
they suggested to use custom stubs to achieve that |
This fixes #8268.
Basically I added the
/** @template T of int|string */
in the BackedEnum stub and then i managed to add issues whenthe implemented template type mismatches with the backing type.
Furhtermore, it's not mandatory to add the@implements annotation if the backing type is just int or string
Further cases can be seen in the tests.
I am not sure this is the right implementation. Let me know if, in case, we can make some adjustments.