I don't know if this actually makes sense or not, I might be oversimplifying things or missing something, but if it does, I think it would be extremely helpful to alter Psalm to work this way. It could get rid of a lot of the fuss about using @template vs @template-covariant, which can get pretty annoying. I understand there is a point to the distinction and it makes sense for Psalm to care about it, the documentation does a good job of explaining this.
It seems to me there are 2 cases where the distinction is unnecessary and Psalm could not emit any issues where it currently does.
One case can be illustrated by a collection class using templates that is immutable, being used by a function that expects a specific type that is compatible, but not the same. Here is an example: https://psalm.dev/r/a3891f5a67
In that example since ImmutableCollection is @psalm-immutable, it cannot be modified, so it is safe to pass it to a function that works with AbstractAnimal without worrying the types will get altered. At least that is my hope/idea.
The second case is if the function you are passing it to is either pure or mutation free: https://psalm.dev/r/056d6bdcf3
An example of the benefits is these collection classes could then implement interfaces such as ArrayAccess or IteratorAggregate, which don't work with @template-covariant keys and values.
I don't know if this actually makes sense or not, I might be oversimplifying things or missing something, but if it does, I think it would be extremely helpful to alter Psalm to work this way. It could get rid of a lot of the fuss about using
@template
vs@template-covariant
, which can get pretty annoying. I understand there is a point to the distinction and it makes sense for Psalm to care about it, the documentation does a good job of explaining this.It seems to me there are 2 cases where the distinction is unnecessary and Psalm could not emit any issues where it currently does.
One case can be illustrated by a collection class using templates that is immutable, being used by a function that expects a specific type that is compatible, but not the same. Here is an example: https://psalm.dev/r/a3891f5a67 In that example since ImmutableCollection is
@psalm-immutable
, it cannot be modified, so it is safe to pass it to a function that works with AbstractAnimal without worrying the types will get altered. At least that is my hope/idea.The second case is if the function you are passing it to is either pure or mutation free: https://psalm.dev/r/056d6bdcf3
An example of the benefits is these collection classes could then implement interfaces such as
ArrayAccess
orIteratorAggregate
, which don't work with@template-covariant
keys and values.