Do not generalize class-string during template type inference #1038
Conversation
99cd1d5 to
80c2c47
Compare
9e9234c to
80c2c47
Compare
80c2c47 to
fe9b4c9
Compare
|
Thank you, I like this and appreciate it! About the generics generalization problem - it's really really tricky. People have different needs and I worry that we can't guess them. I think that PHPStan currently has a little logic that half-works - if the Collection had I also have this issue phpstan/phpstan#6433 and phpstan/phpstan#6695 that I might solve thanks to this PR. It's another case where less precise generalization is welcome. One solution might be to put the user in control of the problem with some annotation like |
|
@ondrejmirtes It's worth noting that TypeScript has a bit of a related dilemma involving how to make a type less specific without having to use the (type-unsafe) |
This prevents generalization of
class-stringtypes during template type inference.Fixes phpstan/phpstan#6505
Note:
I'm now wondering if we should generalize inferred types at all. Generalization allows expressions such as
new Foo(1)to be inferred asFoo<int>rather thanFoo<1>, which is useful. However, sometimes we may actually want aFoo<1>, and the current behavior makes this impossible.It could be useful to be able to create a
Foo<non-empty-string>, aFoo<numeric-string>, or aFoo<int<100,200>>.If we stopped generalizing at all, a
new Foo(1)would infer toFoo<1>, andnew Collection([1,2,3])would infer toCollection<1|2|3>, which is less useful in most case, but it gives the control to the user. The user would be able to generalize the type manually, like this:or like this: