PHPStan and psalm doesn't handle iterable templates the same way

[VincentLanglet]

I'm trying to remove the option

checkMissingIterableValueType: false

from my config. And I'm getting an issue with the following example.

https://phpstan.org/r/6bf76fee-b55d-4177-81a0-e49fd5e6a6f0

Because the Result is extending IteratorAggregate, PHPStan is requesting

parameter $result with no value type specified in iterable type Result.

But if I solve it with Result<string, mixed>, I'm getting from psalm
https://psalm.dev/r/66ceab43ac

Result<string, mixed> has too many template params, expecting 0

If a @template is provided, both psalm and phpstan respect it (and phpstan doesn't complain anymore about the iterable things and complain instead about the generic without type).
But when no @template was provided, psalm consider the class/interface like a non-generics one, but phpstan instead rely the job on the IteratorAggregate @template description.

Since, psalm is reading phpstan-param annotation, the only solution I found is

@phpstan-param Result<string, mixed>
@psalm-param Result

Dunno which strategy is better, but I think some consistency should be added to avoid this situation.
WDYT @ondrejmirtes, @orklah, @weirdan ?

[ondrejmirtes]

You can get rid of this problem if you specify the generic types of \IteratorAggregate and other extended interfaces: https://phpstan.org/r/aa5bc715-e1ad-460c-9f39-1b0c09546f47

Neither tool should have a problem with that.

[VincentLanglet]

Sure I will.
But don't you think it make sens for psalm and phpstan to also take the same decision ?

I kinda find the psalm behavior more intuitive ; no template = not a generic.
Is there a specific reason for the phpstan decision to pass the template from IteratorAgregate (but not others) ?

[orklah]

Psalm is kinda weird for not requiring @template-implements and I find PHPStan to be kinda weird to require templates indirectly... (It makes me wonder a lot about what PHPStan does if there's multiple interface with different templates... does it add them all in a random order?)

[VincentLanglet]

Psalm is kinda weird for not requiring @template-implements

Can become a feature request for psalm

I find PHPStan to be kinda weird to require templates indirectly... (It makes me wonder a lot about what PHPStan does if there's multiple interface with different templates... does it add them all in a random order?)

This seems to only occur for iterable.
So it just implicitly become a <TKey, TValue> generic.

[ondrejmirtes]

I don't know what you deduced exactly, but what's happening in PHPStan is:

• When PHPStan sees an iterable object without specified iterable value, it tells you on level 6 with checkMissingIterableValueType: true enabled. More about possible solutions here: https://phpstan.org/blog/solving-phpstan-no-value-type-specified-in-iterable-type
• PHPStan requires specifying template types (aka "type variables") for generic objects in typehints and in extends and implements on level 6. This can be turned off with checkGenericClassInNonGenericObjectType: false.
• If an object is iterable but not generic, it understands Foo<X, Y> and Foo<X> syntax - the final type is Foo&iterable<X, Y> or Foo&iterable<Y>. This is because such syntax exists in the wild and was also supported by PhpStorm long before generics. It has nothing to do with generics. Psalm could consider to implement the same heuristics if it doesn't already.
• Another supported syntax for the point above is Foo|X[] equivalent to Foo&iterable<X>.

[VincentLanglet]

• If an object is iterable but not generic, it understands Foo<X, Y> and Foo<X> syntax - the final type is Foo&iterable<X, Y> or Foo&iterable<Y>. This is because such syntax exists in the wild and was also supported by PhpStorm long before generics. It has nothing to do with generics. Psalm could consider to implement the same heuristics if it doesn't already.

Thanks for the explanation, I'll go with the Foo&iterable<X, Y> notation then.
I don't find Foo<X, Y> intuitive because it make me thinks to a generic instead.

Psalm have an option

Allow PHPStorm generic annotations (e.g. Traversable|string[])

It transform Foo|iterable<X, Y> to Foo<X, Y> when Foo was a generics but don't do it in the other way.
I don't know if more must be supported.

First, maybe the bug vimeo/psalm#6340 should be fixed ^^

[weirdan]

Either fix it, as suggested by @ondrejmirtes, or stub it.